At the moment, VisualEditor gets stuck when trying to load on certian pages (ref T326169). In these cirumstances, as well as other cirumstances such as when the browser is too old/incompatible, or if certain extensions are unintentionally causing VE's javascript to break or otherwise be blocked or not work correctly, or if the editor's Internet connection is sufficiently slow that the JavaScript doesn't finish loading in a reasonable amount of time, etc. In any of those cases, they will see a link to "try again" which should reload the page with the wikitext editor shown and VE not engaged.

This is what that link looks like today, e.g. when navigating to https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Multi-DC_MediaWiki?action=edit when logged-out or on an account with VE enabled.

However, this link is inacessible because it is part of the body element that VE's init phase "mutes" with reduced opacity and pointer-events: none; rules set. This means any attempt to click them is ignored. The link is not followed by the browser.

When debugging this, I find the link is meant to point to https://www.mediawiki.org/w/index.php?action=edit&title=Wikimedia_Performance_Team%2FMulti-DC_MediaWiki&venoscript=1. Note the venoscript=1 parameter. When going there directly, to see if there are additional bugs perhaps, I find that doesn't work either. It renders as follows:

This advertised link correctly replaces the fallback message with the wikitext editor. However, VE still attempts to initiate itself, and still does to by muting the page, and thus making the wikitext editor unclickable. I'm tentatively tagging this as a Regression, but it is possible that I misremember how this worked in 2015.