I think I identified the cause of the problem: rEVEDb2718b186abc: Separate handling of document HTML and edit metadata.

In short: we accidentally removed an early return statement when moving code around, which in rare cases (editing a page that was very recently edited) causes the editor to attempt to load twice, in turn causing this bug.

Details below. Maybe this helps someone debug or avoid a similar problem in the future.

What seems to be happening is that the event handler ve.init.mw.ArticleTarget#updateToolbarSaveButtonState, which should be bound to ve.dm.Surface history event, is mysteriously missing. This method is responsible for enabling/disabling the "Publish" button.

I found that there is only one place where this handler is bound (ve.init.mw.ArticleTarget#surfaceReady) and only one where it is removed (ve.init.mw.ArticleTarget#teardown), so my working theory was that either teardown is called too soon, or ready is not called at all.

I started investigating the first idea (it's a lot easier to find out why something happens than why it doesn't happen, since you can put breakpoints on it). I spent a lot more time trying to see if teardown was being called too soon and being frustrated by the issue magically disappearing when I tried to debug it¹.

At first I found and investigated the code which creates and then tears down a "dummy surface", which is never shown, and its purpose is to allow the toolbar to be created while we're loading the page, rather than afterwards. But this didn't look like the cause of the problem.

Finally I placed breakpoints all over the place and found that ve.init.mw.ArticleTarget#surfaceReady was sometimes called twice during loading the editor with two difference surfaces. First time, it sets up everything with the first surface; then it is called with the second surface, but at this point the Target is in a broken state and it thinks loading the editor was cancelled and it does nothing with the second surface (this happens in ve.init.mw.DesktopArticleTarget#surfaceReady). So our event handler on the second surface (the one that ends up being used) is never bound!

Why is it called twice? I compared the two stack traces to find what is calling the method (copied from Chrome's debugger).

The top and bottom end of them is very similar, the difference is in the middle. The first one is reached via ve.init.mw.ArticleTarget.load, while the second via ve.init.mw.ArticleTarget.load→ve.init.mw.ArticleTarget.parseMetadata→ve.init.mw.ArticleTarget.load (recursively calling load() twice). Apparently the issue occurs when we have to retry loading the page content!

Background: to open the editor, VisualEditor has to separately download page content and page metadata². In the configuration used on Wikipedia, page content is downloaded from RESTBase, while page metadata is downloaded from MediaWiki API³. Unfortunately, due to caching, the data returned by those services can be generated from a different revisions of the page – especially if the page was very recently edited. When this occurs, we retry, explicitly specifying we want to edit the more recent of the two revisions that we got the results for⁴.

Apparently changes in rEVEDb2718b186abc: Separate handling of document HTML and edit metadata made it so that retrying does not abort the current attempt to load the page. Both the original load and the retried load complete, setting up two surfaces (you can actually see the first surface with the old page content appear for a fraction of a second – not that you can tell the difference when editing a real article).

It's actually a wonder that nothing else breaks when this happens. Every feature of the editor appears to work correctly, except for the "Publish" button. (And I suppose it might cause some weirdness when we log event timings – we might have two "load success" events for some "load attempt" events?)

¹ I can now guess that pausing the process at various breakpoints made it slow enough that I never ran into the case where RESTBase returns cached data belonging to a different revision and we have to retry loading, which is necessary to trigger this bug.
² This includes: edit notices; configuration for checkboxes in the save form (this depends on whether user is allowed to watch the page, mark edit as minor, or mark edit as reviewed through FlaggedRevs/PendingChanges); list of templates and redlinks on the page.
³ You can also configure it to download both of these from MediaWiki API, in which case the issue does not occur. I use this configuration locally, which is why I couldn't reproduce. This way is slower, since MediaWiki API itself has to get the page content from RESTBase.
⁴ Why not always specify we want to edit the latest revision of the page? Because someone else might have edited the page while you were reading it, so the latest revision VisualEditor knows of (the one you're reading) might not be the real latest revision. Figuring out which is the real latest revision would require another API query, making loading slower in the common case.