That's the problem with increasing fragmentation as an n+1 of the same thing and trying to do everything yourself rather than delegating and scaling effort and expertise via crowdsourcing and outsourcing through plugin maintainers.

An "opposite" of the Atom approach appears to be an extreme overreaction (rather than a sensible middle way) and fails to solve the problems it brought: a slow, wasteful platform and a tradition of abandoned, fragmented plugins (also a problem with Vim/neovim, emacs, VSCode, and JetBrains).

A balance would be a curated plugin marketplace requiring quality, continuing maintenance, and support. Atom, VSCode, and JetBrains have some curation, but not enough. I don't know how to solve this other than to charge end users subscription fees and pay people for their efforts.

Also, that brings up the problem of monetization. A number of plugin authors insist on trial, freemium, or paid-only plugins because it's not a spare time hobby for them. Lacking monetization, some plugins won't ever be created.

So I don't see how zed will solve any problem other that being art as wonderful technology applied to a tough, busy, competitive category without enough unique, competitive advantages to self-reinforce increased adoption. As such, it seems unlikely to ever morph into a complete and useful IDE to uniformly support every development niche. Even now, I have difficulty finding a usable Haskell IDE with commercial providers such as VSCode or JetBrains to wonder if zed will somehow manage to be better than any of them and/or vim.

TL;DR: I think Zed project leaders were overly ambitious, unrealistic, and failed to anticipate the endgame.