It seems kinda similar, but I'm not familiar with OCL
or Xtext to know that.
I do agree that trying to fix a signification limitation of
some layer (Xtext in this case) in a layer above (OCL?)
usually works pretty badly, if at all.
I actually had a very similar problem here. Originally I
wanted the Platform-Text changes to be very minimal: only to
expose the minimal save code of the the text buffers as a
method (ie, the part of the save code that could be executed
outside the UI). Then, I could create an Auto-Save Manager
externally (outside of Platform-Text). However it was soon
apparent that doing it this way would have severe design
flaws and unfixable concurrency bugs. A correct
implementation of an asynchronous auto-save needs to have it
built-in Platform-Text, the text buffer itself needs to know
about it.
I don't know what's the deal with XText, but I noticed
something peculiar in the stack-trace: XText is still using
org.eclipse.ui.editors.text.FileDocumentProvider. I was
wondering about this class quite recently, asked in
Platform-UI ML what's the deal with that (
https://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg06902.html
)
FileDocumentProvider actually duplicates a lot of the code in
the AbstractFileBuffer subclasses, which is the code I had to
rework for my contribution.