In reply to bellasys.

Sounds interesting. There are a few issues:

1) something built for a very specific need can sometimes be hard to adapt to a more general case.

2) and sometimes not... but it might still be best suited for some uses and not others (i.e. I can see an admin backend that's designed to be used by a newsroom being very different in exposed capabilities and user interface from an admin design for a single blogger.

The current admin is, frankly, not good anymore. It's not terrible, but it doesn't adapt well to different uses and installing plugins can leave a mishmash of menus, etc.

What we need to do is to have different admins for different uses:

a) A portfolio admin

b) a news site/magazine admin

c) a simple, Medium-like blogging admin

and so on.

A start would be a modern, highly configurable admin that used the entire screen. The Problem with the current focus on Customizer is that it feels like the team wants to expand customizer into some Frankenstein monster of an admin. What I'd do is this:

Define what the Customizer should do and what its limits are to be. To me, the name implies that it's there to customize some base look and feel and templates content (the tagline, etc), not to do full on content editing or other admin tasks.

Define what other needs are there that the customizer API can do (and what additions might be needed to the API). Call this project New Admin.

Rename the API - if you call it the Customizer API... guess what people think? Right.