We've started working on a preference that will let you return to the previous message composer. We don't have a specific release date to share right now — it's this team's top and only priority, however, and we expect to have it available on the desktop within a couple of weeks
===
"team's top and only priority"
I guess they need to learn how to be efficient if they need several weeks to add a checkbox to change one setting
The larger a product is, and the more people involved, the more steps and phases are needed to keep everything running smoothly. A dev shop with fewer people can be more efficient because there's less communication overhead, individuals wear more hats. But it doesn't scale.
It's also an artifact of Agile, SCRUM especially. If you keep a fungible pool of devs who can be redirected on a weekly basis, they don't necessarily have knowledge or expertise in the area of code they're working on, so there needs to be extra investigation time, sync on technical details, and more QA to cover omissions and unwanted interactions from lack of total knowledge. Component ownership is less susceptible to this but you lose some agility as dev fungibility is reduced.
It's probably more the layers and layers of bureaucracy they have to go through to push any changes. They probably need at least 3 meetings, and several people to sign off on it.
Charitably, there's (e.g.) accessibility issues that need to be addressed on "new" features like the menus, and they need to be sure they're not going to be reamed for the new feature in the same way they are for this. Also testing. Several weeks is still high but not ridiculous.
My (entirely speculation) suspicion is that the old editor had a lot of tech debt, that the team was excited to delete, and since they're now having to put it back, having to make it compatible with the new editor.
===
"team's top and only priority"
I guess they need to learn how to be efficient if they need several weeks to add a checkbox to change one setting