There are problems. Suppose, we define a new variation selector that will stay with the preceding mark under normalization.
Now consider what happens when implementations conforming to a standard of Unicode that does not know about the new character normalizes the sequence BC CM180 CM160 NVS BC = Base Character CM# = Combining Mark of ccc # NVS = New Variation Selector.
As far as it knows, the new variation selector is an undefined character with a ccc of 0, so when normalizing this it will reorder it as: BC CM160 CM180 NVS Now lets have this "normalized" string be passed on to an implementation which knows about this NVS, There were two schemes I proposed for implementing this NVS. Both have problems, as I will point out below.
No implementation supporting version X can normalize all data containing characters from a later release. If that was a requirement we could never add combining characters. What is required is that all later implementation normalize any data from version X the same way a version X implementation would have done and to not change already normalized data. I think it's strictly speaking the latter aspect that's guaranteed. ...
Adding Variation Selectors with non-zero canonical combining classes is possible, but I fail to see the benefits from adding new Variation Selectors on the SSP outweighing the benefits of defining new vowel marks in the Hebrew block. It's not as if the Hebrew block does not have the space to add additional vowel points, and frankly, anything on Plane 0 is likelier to be implemented sooner and on a wider set of platforms..
This is the essential argument.
A./
