Since DOIs are opaque, that doesn't preclude future use of a numeric prefix as well for something completely different.
Right. Now I see what the problem is -- opaque identifiers are jargon from databases (I did my PhD research on them) and many IETFers don't understand what they are.
The point of an opaque identifier is that you can make no assumptions whatsoever about what its structure or format is. You can just find it somehow, and you can hand it back to services that use it to look up what it refers to.
At the moment, the code happens to use the database field published as the <doc-id> in the XML RFC index to create the DOI. But tomorrow the code might do something else. This week the DOI it assigned to RFC 7612 was 10.17487/RFC7612 but next week the DOI it assigns to RFC 7613 might be 10.17487/gazornplatz.
This isn't an idle threat. The RFC production software stores the DOI for each document in a separate field in the database. There is literally one line of code that creates new DOIs -- change that, and all future DOIs will have some other form. (Existing DOIs are in the database and won't change. That's what stable means.)
The only, and I mean *ONLY* way to find the DOI for an RFC is to look it up. That's not a big deal, because the the DOIs are now included in the mechanically created RFC index and bibxml files, so anyone using the usual xml2rfc tools will get the correct DOIs automatically.
The draft should be clear about whether or not leading zeros are used for low-numbered documents.
I hope it's now clear why that would be a bad idea, and also why you shouldn't make any assumptions about what the DOIs of RFCs after RFC9999 will be.
R's, John