@cephie "do you see customisability mostly as a means to paper over shortcomings in design, then?"

Only partly. In theory, customizability *should* be about allowing someone to nudge and shape their system so that it's perfect for them. *In practice*, however, I find that in Linux-land it is almost always used as a means to paper over design shortcomings.

This is pretty obvious from how unnecessarily difficult a lot of things are to set up, with very little standardization between projects going on, even on points that absolutely could be standardized.

"What's meant to happen when folks run up against limitations if they find themselves not in the "most people" category?"

This is why there *should* still be avenues for customization - but crucially, this is an edgecase, and it should be treated as such, instead of being treated as the main case like it is now.

As a simplified example, if you're building a desktop environment, you could take roughly two approaches:
1. Add extensibility at every layer of the stack, so that every bit of internals of the DE is customizable, whether at a low or a high level.
2. Add extensibility at one well-specified point in the stack; either you use the whole DE as-is, or you use none of it, or you replace a few specific components in it wholesale, but that's the end of your options.

If you're trying to maximize customizability, then on paper approach 1 sounds optimal; you can change anything very easily! It optimizes for people wanting to customize.

But the flipside of that is that your reliability suffers (a lot of variable moving parts), you cannot do architectural reworks *at all* anymore (because all the extensibility surfaces are 'locked in' architecturally), and it becomes extremely difficult to reason about how the codebase works, and therefore to maintain it.

That is why approach 2 makes more sense; you optimize for the common case of "I just need my computer to be a tool", make maintenance vastly simpler and the code vastly more reliable, and leave sufficient space for the tinkerers to replace parts that they don't like.

That customization will require a bit more work in approach 2, but this is IMO a reasonable burden to place on the tinkerer; because the alternative in approach 1 is that the burden of customizability is placed on the *common case* user instead.

Firefox used to do approach 1 for its extensions. It single-handedly held them back from being able to speed up their browser for years, until they eventually replaced the extension API with one that followed approach 2. Suddenly, Firefox became vastly more usable for most people.

"Perhaps there's a zealous push toward "customise all the things!" (even those things that are dangerous, or don't make sense) that i've missed,"

Pretty much. Any time anything vaguely usable is suggested, an extremely vocal contingent of angry nerds descend on whoever is doing it to complain about how it isn't perfectly interoperable with their bespoke setup, practically starting a misinformation campaign. See: systemd, pipewire, and so on.