This was a requirement that was always envisaged for the Model Relay/MT system but it was unexpected that almost our very first application of the system to a real problem would end up requiring it. This requirement arose as part of the metadata panel work and is written up more fully in
FLUID-5307. Not all model transformation rules are completely invertible - sometimes multiple values on one side of the transform are associated with a single value on the other. In the case of a static, one-shot "model transformation" run, there's not much we can do about this since we have no ready access to a source of additional information that could disambiguate the inverse. However, when operating a constantly running model relay associated with the transformation rule (most likely, accompanied with a live updating UI showing the changing values), there is always a "current value" associated with both ends of the relay link. This can be used to improve the quality of inversion that we offer.
In order to gain access to this improved inversion quality, we need to make various upgrades throughout the pipeline. An author of a transformation rule needs to be able to specify that it participates in the "pseudoinverse" system, and commit to providing a "principal inverse" value when the link is operated in the noninvertible direction. Perhaps as a performance hint it might help if the transformation rule can somehow "out of band" report that the particular value is a "principal inverse" rather than a "perfect inverse". The MR/MT system when it finds such a value on one side of a link will leave it undisturbed if when running it back through the other leg of the link finds that it inverts to the same value. It will only make use of the "principal inverse" value in the case where the value on the other side of the link doesn't correspond to any of the possible values associated with it by the transformation rule. This would be much clearer with a diagram.
The principal transformation rule that could benefit from this immediately is the "valueMapper" which would need to be upgraded considerably - this kind of discussion is beginning to suggest that this rule will increasingly be seen as the "standard discrete transformation rule" in that it is capable of having any kind of mapping specified to it purely in terms of examples. "continuous" rules operating on numbers such as the linearScale mapper will continue to be the main alternatives - but these are typically "fully invertible" except in special cases.