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.
Now I wonder why XText is using FileDocumentProvider.