Vassal Reference Manual and Traits

OK. The Vassal reference manual stresses the correct ordering of traits with game pieces. But does not offer a way to achieve this. The manual offers guidance and a really good quide for the nice/right/perfect trait order. There will be always some exceptions, but they can be slotted in at the appropriate prototype slot to minimise ‘disruption’.
How about this:
Developers be encouraged to develop prototypes as blocks.
proto1, proto2, etc.
Proto being aircraft, land, navy, et al.
So then I have (for aircraft), acft1, acft 2, etc. 1 contains rotatables, 2 contains can (rotate/pivot) & mat cargo. Continue down the line IAW with VASSAL Reference Manual (
You end up with 14 prototypes that can be the main part of a game piece definition. Some may actually be empty, but what does that matter. Developers can add new stuff to any of the protos and generally be aligned with the ‘best’ trait order.
You do stress the importance of trait order. So why not actually advise the optimal achievement of this.

FYI, I’m currently in the process of doing this. Interesting and mentally consuming process. I’m finding that some of the stuff I did way back before I knew little about Vassal I can now get better with using. The Marker trait can be quite ‘powerful’. Essentially, the ability to use multiple markers within one trait. Like cool.

Then this:
7 markers, most with 0,1 values. (I now see that a 0 or 1 for the first value can denote a corp or div, no need for a separate 0/1 - damn. I’ll amend what I’ve already done. Drats. (the aircraft ones were easier to implement). Ground pounders are just so varied.
I’ve yet to work out how I can use this fully, but I do know that many disparate prototypes can now be rolled into the overall scheme of land1, land 2, etc. I do know that I’ll need a bunch of restrict commands, but they are simple given the attributes given to a unit by the marker.
There are some prototypes the apply to all, or some that apply to most. I have called these ‘common’. I’ve also named them with the convention of 7, 8, etc as to where they should sit within a game piece prototype. My expectation is that I’ll have a game piece with all 14 prototypes and some prototypes layered within that construct. Let’s say - acft1 (rotatables), acft2 (can rotate/pivot), acft3 (move trail, layers, mark when moved, text labels, area of effect, and so on. I’ll also have a ‘delete’ common called delete5, the 5 indicating where it should be placed in the game piece prototype.

BTW the default Delete is just so wrong. CTRL D is but a mere key away from CTRL F (used for flip). I had to use CRTL Shift D for delete and a Trigger to ‘point’ users to that. This comes from players of the game. I make no comment on their ability for pressing the right keys. But CTRL D for DELETE is definitely NOT an option.

Anyways, I hope this missive may be of some help to you.
Please excuse my verbosity. I felt that a somewhat detailed account did need to be given.