Not a problem at all - have done this multiple times.
1. Can add a section to the stateBasedVersioning.xml file at any time as long as the Revisions are unique (cannot re-use Rev A). This can be tricky, but if adding a numeric series before the letters, can be made to work.
2. Sequence defined in the xml file and loaded to the database can be utilized differently by product/library context. In one Product for example, can set all data to start with Rev 1, 2, 3...the A, B, C when ready while in another Product, all data starts with Rev A, B, C.
3. For the situation described (use the reverse, letters, then Numbers (common in Europe)), have to verify thru testing whether thru the lifecycle selection of NUMERIC / MILSTD for each state that an earlier seed can be invoked after a later one has been used (e.g. Revise from Rev B to Rev 1). I haven't actually tried this but believe it can be done. I may try this at home tonight. May in fact not be possible but worth having some facts.
If PTC said it would corrupt the database, they are likely being very cautious on this - worth testing thoroughly on a rehosted non-prod system but should be possible. Cannot recover from putting this in place and continuing work if in fact it can't be done.
Note that the xml file is just a way to load the database - it is not "read" except when loading to the database.
Key thing is calling the first Revision of each seed via Revise in the lifecycle configuration.
Note: May need to clear all data from the versionseriessortid table and command it to be repopulated. In the same system, Rev A is after or before Rev 1 for data depending on the context. Cannot move the data because of this of course.
