Haha, it’s not a requirement, just might be a bit friendlier than FULLY_VECTORED when combined with the existing name components. Overly long names can become a bit unwieldy to use, but if you find it clearer the other way then you’re welcome to submit your PR the way you want to 
Hmmm, not sure how that should best be handled. They’re fully defined by a single thruster (assuming similar geometry), but there are technically 8 different configurations (two of which likely aren’t useful), and naming 6 extra configurations that are very similar seems quite painful.
I’ve had this response half-written for multiple days now - I wrote some code a few days ago to generate the different configurations, which I think is correct (it seems to be generating the BlueROV2 ones correctly at least), and I was planning to add some basic plotting for confirmation but haven’t got around to it yet.
I discussed this a bit internally and @williangalvani mentioned we can likely follow ArduCopter’s approach of making the frame definition dynamically adjustable with lua scripting, in which case new frames wouldn’t even require building ArduSub or flashing a new firmware. That’s something I’ve wanted for a while, but it would still need some kind of templating built around it to be simple to use for common configurations (presumably it’s still annoying to have to specify all the values manually in a script, even if doing so means you get to avoid having to build and flash the firmware).