Note that there have been few if any active gnome 3 developers on this thread. (I hedge that because I don't know for sure who everyone is.) I had nothing to do with gnome 3 for example. The current developers aren't getting involved. Probably wise.
> mechanism over policy, i;e; pushing policy decisions up to the end user.
Been meaning for years to write a blog post about the bogosity of that old thing ;-) (I've normally seen it used to explain separation of X11 from toolkit/WM/desktop, not separation of desktop from user, though...)
The problem is that "policy" and "mechanism" are relative rather than absolute terms. Every hunk of code is policy for stuff "below" it in the stack and mechanism for stuff "above" it. So the real question about a piece of code is its role (what is it policy for, and what is it mechanism for). "What does this bit of code define, and what does it leave alone, and what does it have nothing to do with"
Since they are relative terms they don't mean anything without filling in "policy for ____" and "mechanism for ____" and then it isn't a principle that tells you what to do anymore, it's just a judgment about what you want in the "____"
It can be used to justify anything because you can always claim _accurately_ that a given hunk of code is a mechanism AND a policy, you just have to put the right thing in the "for ____" to prove it. X11 is mechanism for the window manager. X11 is policy for the graphics driver.
If you take "mechanism not policy" more abstractly you could say it just means "everything should be as flexible as possible to allow the policy above it to do what it wants" and to that I'd say YAGNI. Bloat bloat bloat.