100% agree with @Simon_JB and @Matt_Blais that a “highlight changes” will be important for this feature, at least long-term. Initial release can be without that, but to really be a good implementation it should have version differencing, ideally between arbitrary versions, but at least between immediately successive ones. Once again I’d point to Discourse as a pretty good implementation. 
Although I don’t think it does arbitrary version comparison (that one’s not a must though, as I say).
Two other things I’d love to have, that sort of work together. One is Named Versions, the other is Copy version to new document. The use case here, for example, is let’s say I make a proposal document and it is version 1.0. I send it to an external client for review. They request some changes, I make those, then some other team members make some changes, there are many revisions until a 1.1 of the doc which we send to the client. Later a different client wants something similar to what was in 1.0 of our proposal. The one we sent to the first client was a PDF, and nobody wants to edit a PDF or copy the text out into a doc to redo it. We could try to edit 1.1 back to 1.0, but that sucks too when we already have the 1.0 version in there somewhere. We can check the date of that PDF export to find the approximate revision, but if there were several that day it might be hard to find the exact one. A named version would let us call it “1.0” when we export that version, then return immediately to that version at any time in the future. Then once we do find it, it would be nice to be able to just copy that out to a new doc to start a new version/“fork”. This may sound like a bit of a contrived case but I do things like this all the time in my day job, usually using GDocs.
I do want to say, though, that these latter two features are definite “nice to haves”, but whether you should work on them obviously depends on how useful they are to others, how long they would take, and how much they fit with the sophistication you want Fibery docs to have. I don’t need to remind you of that (Fibery team), I more just want to acknowledge that I’m aware that not everything that would be “nice to have” should be implemented. They are indispensable features in Google Docs in my opinion, but may be out of scope for Fibery. Certainly there are other things I’d want to see developed before these, if it was a choice between, say, improved activity/notifications features and named version/copy version.