I am reopening this cause the underlying problem still exists, even with presence. Sure we show that two people are editing. But only one person wins now and another loses.
We can sort this out very cleanly if our edit API always includes “this is the revision I expect to be it” with the payload and raises if the revision does not match.
So the process would be:
User A: starts editing (revision is 1)
User B: starts editing (revision is 1)
User A: hits save (current revision is 1) -> 200
User B: hits save (current revision is 1) -> 409
User B: presented with “It looks like the post was updated since you started editing, save anyway? (Yes, No)”
In theory we could do automatic conflict resolution as well which could make the wiki use cases a bit stronger. (calculate diff based off revision, and attempt to apply it to latest)
I do not want to gold plate the feature for the next release with full on conflict resolution windows proposed bye @alehandrof, that can come later. But at least saying “on no, you are going to nuke someone’s edit” would be nice.
Overall, the issue is a lot more of an issue if the community have lots of wiki topics.
That would be awesome, thanks so much!
Just stating the obvious here: one thing that kinda helps is to spread larger wiki post into several smaller ones and perhaps linking them together in the OP.
This might be a silly idea, but what about pre-empting a revision number whenever the editor is fired, so that both revisions can be saved, and then after the conflict resolution can happen? If there’s no save, the revision can be dropped as a no-op.
I worry cause effectively edits still get nuked for somebody and on large wikis it is very unlikely you would notice it till too late.
@nbianca added a safeguard 
https://github.com/discourse/discourse/commit/f60b10d090171c49134b20abcfb089ebb94fad21
Sure! 728 screenshots below 
I see, I was hoping for a are you sure kind of prompt here vs this flow
It’s not exactly what I had in mind either but it is definitely better than the old “silently overwrite” behavior, so I guess we can improve it more later?
A small follow-up on the edit conflict feature.
Now the edit conflict shows as soon as a draft is saved (every 2 seconds or so).
The other logic (the one that is triggered on submitting the changes) is still there.
Sooo nice! 
One very small (I hope?) tweak… instead of the 
can we show the small avatar of the user who the (most recent, since in theory there could be an infinite number of editing users 
) edit conflict is with? My thinking is, this would allow you to ping that person and ask them about their edits?
Is it outside the realm of possibility to diff and compare edits in the same way that we compare versions today?
We’re assuming that changes will conflict and work will be lost, but the possibility exists that two editors are making approximately equal changes.
It’s possible but wayyyy more work for not so much added value. We’re just ensuring no work is lost.
It is more work certainly as @zogstrip said but yeah we could diff against the original in both cases and just apply the diff leaving us still to deal with potential merge conflicts.
But I feel this is an optimization for later, not one for today, would far prefer investing in making other aspects of wiki better.
Just asking, why not make the Wiki a collaborative real-time editor like Google Docs?
I’d say the answer is 'cause it’s bloody complicated` and maybe outside of a scope? But I would for sure love that 
have you seen the collude plugin? it works reasonably well.