The idea behind vendor prefixes is that they are implementations of ideas before conventions have been established. When two vendors implement something simultaneously but pre-spec, it's hard to tell which one will end up being canonical.
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.
I don't know if it's really a big deal to set up a general convention, and when new features appear, just discuss it with W3C and/or other vendors, and use it. These are the minor kinds of problems that can be solved in theory with a few emails and in practice with a 2 months thread on a discussion board (but still better than a mess)
But it isn't a mess. Finalized names are selected as part of the standardization process. That's exactly what TFA was saying: the standardization process works, but web developers are being exceptionally lazy.
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.
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.