In the end, everyone would just drop the prefix. Generating parsing it would be also way easier.
Your general convention is probably good, but in 5 years time when n parameters have ended up in your {additional} parameter, people will ask why that, too, doesn't follow a convention. The answer is definitionally that the convention doesn't exist yet, and the vendor prefix is a step on the way to establishing one.
What you're asking for is that the browser engineers should wait until part of the standardization process is done (the naming) before they start on implementation, only to potentially have to rewrite things once a finalized name is selected. Not going to happen.
border-bottom-right-radius vs border-radius-bottomright, please.
Either use some consistent way of naming as you do with other properties, or just pick a f*n name and use it.
If it was some real competing ideas on the RENDERING of the visual effect defined by the property, I could understand, but the mere name of css properties is not the place to be creative. Just discuss it for 1 hour with other vendors, come to a name and USE IT.
This was just the quickest/most famous/easiest example I could think of. The other I referenced is more subtle. For gradients before standardization, Firefox included the type of gradient in the property definition, "background: -moz-linear-gradient(...)", whereas Webkit made it a parameter to the function, "background: -webkit-gradient(linear, ...)".
The problem is that neither vendor is willing to solve it in one hour. They want to get their own way. It's simply arrogance.
Webkit Dev (speaking to Webkit Program Manager) -- Hey! I've figured out a way we can give divs rounded corners.
Webkit PM -- That's cool, what do you call it?
Webkit Dev -- Well, for the bottom right it's "border-bottom-right-radius"
Webkit PM -- Cool.
<some time later...>
Webkit PM (to Webkit Dev) -- Hey! I just got off the phone with Firefox PM. He says they've also developed a way to give divs rounded corners.
Webkit Dev -- That's cool! I guess it was a needed feature.
Webkit PM -- Yeah...only problem is the name. They decided to call theirs "border-radius-bottomright".
Webkit Dev -- Oh.
Webkit PM -- Sooo, yeah. If you could just change that name.
Webkit Dev -- But we already GM'd the build with that name in it. To change it we'll have to back out of the GM, requalify the build, change the documentation, send out new seeds, redo internationalization, send it back to QA, and declare a new GM. That will push out the release by 3 weeks, and besides, I have 20 bugs in my current backlog that are completely unrelated to border radii. How important is this?
Webkit PM -- Oh...not that important I guess...
Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable.
Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others.
1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2...
2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.