Disclaimer:
Let me start off by apologizing for the blunt tone in this post. I very much appreciate the spirit of openness and hard work that underlies the development side, and I want to thank you for both the hard work in improving the UI and for the time and willingness dedicated to soliciting community feedback. I offer this feedback with some blunt edges because it is important -- you're doing great work, but if you don't do that work carefully then there is a clear potential to cause significant harm, and most of the signs I can see indicate that your current trajectory goes towards that harm.
What follows is intended exclusively as constructive criticism, and I hope it reads as such =).
That said:
This change is extremely alarming from a MathJax perspective.
The design philosophy makes a lot of sense for a lot of sites, but several of the proposed changes (specifically, the removal of the live preview) would be a catastrophe for sites where MathJax is a common or essential part of the site experience. As a reminder, this is no less than 42 sites out of the network total of 176, i.e., 24% of the network sites.
(Also, as pointed out in the comments, there are several other essential site-specific post formatting plugins which are in an identical situation to MathJax, the clearest examples of which are chess, go, furigana and music notation.)
Here are the things that worry me the most:
We could put these previews side by side, or toggle between them like GitHub does, but I think having a preview at all is something we can move beyond.
uh... no it isn't.
Why should any text editing offer a read-only preview state in 2021? Is writing, previewing, noticing a mistake, and moving back to the editor truly better than simply being able to edit the text? Would you accept this interaction model in your word processor?
Yes I would. I already do. This is my main mode of work. In my discipline -- similarly to many of those represented in MathJax-holding SE sites -- the industry standard word processor is LaTeX. Having a separate editor and preview is not only standard, it is the only way to work efficiently.
At the very least, building a WYSIWYG editor for math is a major software undertaking. But, to be blunt, none of the existing solutions, with decades of trajectory, make the bar as a professional standard. (For clarity: it would be absolute nonsense to attempt it here.) Editing math absolutely requires a code-and-preview configuration. As such, if your design philosophy is that "having a preview at all is something we can move beyond", then your design philosophy is blind and deaf to the requirements of the technical sites.
I am of course sympathetic to this concern:
If you’ve ever written long posts, you may be familiar with the feeling of doing a lot of scrolling to get from the end of a preview back to the edit window.
and indeed it can be annoying (though, as has been pointed out, not universally). But that viewpoint is missing another vital aspect of how MathJax works on Stack Exchange, and that is the amazing and extreme convenience of having an instant preview rendered alongside the plain-text Markdown/MathJax source. In fact, the current editor is more convenient than the standard LaTeX editors, due to the speed and constancy of the preview refresh -- it refreshes as soon as anything changes, and it is only limited by the (very fast) speed of the rendering.
In the proposed changes (Markdown source and rich-text preview on the same pane, with a button to switch between them), writing and editing mathematics will become noticeably and significantly harder. To put it bluntly, getting rid of the simultaneous preview kinda shafts the mathy technical sites, bigtime.
Now, I appreciate the points made regarding the age of the code and the difficulty of maintaining it and of using it as a base for further upgrades. It makes complete sense that there is a need to have a better codebase for the editor, and that it should, at the end of deployment, be used across the board throughout the SE network.
... which is why it is essential that the concerns surrounding MathJax form part of the initial design stage. This:
Sites with MathJax are among the last we'd ship this on
is not good enough. The concerns surrounding MathJax are part of the core design decisions that need to be made. If the plan is to wait until the end, once everything has been hammered out and all of those design decisions are set in stone, and hope fingers-crossed that those decisions will work for the 40+ sites that use MathJax, then the plan reads "we don't care if the mathy technical sites end up getting shafted" to me.
If the goal is to have a single codebase work for rich-text-oriented sites and Teams as well as for MathJax-oriented technical sites, then that jointness needs to be recognized from the get-go: the design decisions regarding the preview need to be made now, and a mathy site (math.se, physics.se, stats.se, etc. - your choice) needs to be among the first sites to test it out.
One more thing:
Syntax highlighting in Markdown mode
You’ll notice your Markdown experience is a bit less monotonous because it now responds to the Markdown you use by changing the text in the pane - headings will be larger, bold text will appear bold, as will italics, and links will be in blue and code will be in grey.
That's great! But you also need to turn it off inside MathJax delimiters. Some of those problems have already been pointed out, but I'll say it explicitly here: messing with the formatting like in this screenshot is extremely distracting, utterly useless (in the sense that it is not achieving any of its goals, as it's responding to syntax that's going to produce other output than what the highlighter thinks will happen) and it has no place in a math editor in the 2010s, let alone the 2020s.