ITransientValueService is non-API; documentation indicates the wrong ITransientValueService

If a user wishes to customize the decision whether or not a value is considered transient by the Xtext serializer, they can bind a custom ITransientValueService.

However, there are two different interfaces called ITransientValueService:

1. org.eclipse.xtext.serializer.sequencer.ITransientValueService
2. org.eclipse.xtext.parsetree.reconstr.ITransientValueService

Both are used, but only the org.eclipse.xtext.serializer.sequencer.ITransientValueService seems to have the final say on whether or not to serialize a model element - at least in my use case, which is to have Xtend serialize model elements that have default values. This post by Christian Dietrich seems to agree.

The issues are, then:

1. Non-API
   org.eclipse.xtext.serializer.sequencer.ITransientValueService and the default implementation org.eclipse.xtext.serializer.sequencer.LegacyTransientValueService are non-API. This seems undesirable, as provinding a custom binding is a valid usecase (per the above).
2. Javadoc
   The Javadoc of org.eclipse.xtext.parsetree.reconstr.ITransientValueService and that of its isTransient() method imply that it decides whether a value needs to be serialized, while this is not 100% true.
3. Documentation
   The documentation links to org.eclipse.xtext.parsetree.reconstr.ITransientValueService. (This may be correct for some usecases; I don't fully understand the difference in role between the two ITransientValueServices.)
4. The DefaultRuntimeModule contains a method that binds an org.eclipse.xtext.parsetree.reconstr.ITransientValueService. That means that Eclipse's content assist will offer to overwrite that method, which nudges the user to do that instead of creating a binding method for org.eclipse.xtext.serializer.sequencer.ITransientValueService.

Start by comparing org.eclipse.xtext.serializer.sequencer.ITransientValueService and LegacyTransientValueService with org.eclipse.xtext.parsetree.reconstr.ITransientValueService, then inspect the DefaultRuntimeModule binding. Review the linked runtime concepts documentation and Javadocs; done means the documented interface, API status, and binding guidance accurately reflect the serializer behavior.