I'm not sure I follow all the points you're making. But...

1.) I've created CSV import/export admin functions for models many times and I agree it's a minor customization. I'm not sure why changing templates is a no-go for this or anything else.

2.) To me it seems self-evident that the admin was designed to facilitate model-oriented CRUD operations. The fact that it's hard to integrate non-relational data stores like mongo have nothing to do with the admin, and everything to do with the fact that there is currently no agreed on way to plug NoSQL data stores into Django's ORM. Although this has been is a longstanding point of contention and there was a GSOC project that I think eventually became http://www.allbuttonspressed.com/projects/django-nonrel , my sense is that there just wasn't/isn't enough interest in making this a part of Django core. In other words, this goes well beyond what I would call "admin customization" and get's down to pretty basic questions about what sorts of persistent data stores should be supported by the ORM.

3.) Again, this seems to me to want to be able to stretch the admin beyond what it was designed for. To your point: "the first page must be a list of models regrouped by apps. This is in advanced apps [nonsense], most likely when you use a lot of reusable apps, where the code doesn't reflect the end-user experience, the admin will look ugly. But should the admin reflect or map somehow the end-user experience? It's a 'complex mapping'."

I agree! This is potentially a very complex mapping. While it would be wonderful if there was some way to handle these sorts of things while retaining the easy-to-use, declarative nature of the current ModelAdmin approach, that's a tall order. The right answer at that point might be: build you own admin.

With all props to the current admin, the areas where I see it "starting to show it's age" are skin, user experience, and features. I don't present Rails' ActiveAdmin as a lightyears-ahead-alternative, just an example of an admin that is incrementally better than Django's in those areas I mentioned.

When I say the admin approach to "class-based views" feels disconnected , I mean that while it is technically correct to say that, for example, https://github.com/django/django/blob/master/django/contrib/... is a "class-based" view, it's not a capital-C Class-Based View. In other words, this is an area where features that have been developed in core have not made it back into the admin, even though they could be enormously beneficial and help to make the whole thing more pluggable. That actually seems to be one of the goals of django-admin2, which is great news.

It may be that you and I don't really disagree here all that much. I was responding to the statement of the parent: "try to do anything custom [with the admin] and you're screwed," which I don't think is true. But there are definitions for "custom"--things that go way beyond providing a simple way to model-oriented CRUD operations--that present some real challenges. And frankly, they may go beyond what a general-purpose, easy-to-configure admin can or should do.

(unrelated to my point: the example app of mine I cited does not support filters and actions. It certainly could, if I or someone else had the time to and the need to add it. But it presents some thorny UX problems like "what does it mean to filter out model instances from the list view when the instances are also nodes of a tree? Where do the children go?")