And you hope to captivate the hearts and minds of the open-source developer community? Haven't you seen what happened with earlier versions of GNOME 3 and Unity? We love options. We love settings. We don't want them gone, we just want them neatly organized and tucked away in an inconspicuous corner so that we can tweak them at lunchtime.
You yourself might have never used an obscure feature, such as posting by e-mail, but other people do use it every day, and will never switch unless they can keep using it. In fact, there exists an entire blogging platform (Posterous) that is based on the premise of posting by e-mail. Even my grandfather, who is utterly lost when it comes to regular blogging, can use Posterous because he knows how to send e-mail. Since Posterous is now on life support, I've been considering migrating him to one or another WordPress platform, precisely because WordPress supports posting by e-mail. If your fork removes this feature, it will fall right off my radar. I'm sure that somebody else will be able to tell a similar story regarding any WordPress feature that you think is unnecessary or unrelated to blogging. For example, "No Comments": excellent, now I need to send all my visitors to a third party who specializes in tracking them across the world wide web. Someone who had a blog about online privacy might consider it a case of hypocrisy.
It's easy to drop options and features that you don't see yourself using as part of "blogging". Anyone can do it, and each person who tries will get a product that fits his or her definition of "blogging". Such products, however, won't gain widespread use like WordPress has. A much more difficult but potentially rewarding task is to reorganize options and features so that casual users get sane defaults and power users can tweak to their heart's content. It takes a lot of careful thinking, planning, asking around, and UX experience to get this right, but once you do get it right, the difference can be stunning. As the saying goes, 80% of people only use 20% of features, but each person uses a different 20%.
One solution would be to organize these "extra" features into easily installable plugins, and to have those plugins ready before you sign off on your first official release. That would prevent the kind of negative publicity that surrounded the premature releases of some Linux interfaces. But another section of your write-up gives the impression that you don't want that many plugins, either.
PS: But you should definitely kill the ability to edit themes using the web interface. It's a security nightmare, leaving so many critical files writable by the web server. Also, the split view looks wonderful.
I think this is probably preferable to the overhead of tonnes of plugins??