This is an excellent illustration of why "better defaults" is a gateway to endless bikeshedding. One person's "better defaults" are another person's "why?"
The only "better" defaults are those that match what people already know, not necessarily because they're objectively better but because most people will already know how to use them. You literally can't get a learning curve better than "you already know it".
Konsole has had tabs at the bottom for about 25 years now (I don't recall KDE 1.x, but they were definitely there in 2.x). Who do you prioritize in a design? Everyone who already uses KDE, and expects them at the bottom, or a subset of users who might switch to KDE and expect them at the top?
More importantly, is the position of tabs -- especially one that you can change! -- like, a real, actual problem?
>Who do you prioritize in a design? Everyone who already uses KDE, and expects them at the bottom, or a subset of users who might switch to KDE and expect them at the top?
In KDE's case the "you can just customize it" works both ways though. They could change the defaults and instead and let old users customize it back to the old way it was, rather than every new user customizing it. It comes across as a pretty weak argument.
The reality is that most users are simply bitterly opposed to change, especially in "subjective" parts of the system like UI design, and it has nothing to do with whether or not the change is actually an improvement that helps people, or can be undone with in 1 minute through a KWin tweak, or whatever. The very example you're theorizing about (accomodating new users who don't yet exist through UI improvements) actually has happened before with positive and negative examples e.g. Blender's complete UI overhaul in 2.8 which was widely praised, versus Gimp which continues to receive flack for its UI choices, versus Gnome which people just endlessly argue over both ways. It is not as simple as "New UI bad, old UI good" no matter how common of a mindset (and how over-represented) that is here.
Developers of the project have to balance these concerns as they see fit, and that is their right. Being an older user of the project (or any user, actually) does not mean every decision and plan in the project is going to revolve around you exclusively, at the end of the day.
They shouldn't require wasting time to get the old behavior, though, that's indeed alienating, it should instead be saved to user config and preserved on updates
They "of course never arrive" because of course you never implemented the proper match in behavior
But the old users can have it too, that's what configurability is for, just save the state to user config and don't change any such behavior on upgrades, only for fresh installs
Look to Mozilla and Ubuntu to see and organization and a company that "bet the farm" on new users by systematically breaking everything we loved them for.
The problem with these (and many other UX initiatives) is there isn't a fallback for us who used them from the start.
The lack of fallback is a problem, but that's a different one. And there are even more examples of orgs that didn't bet on new users and simply died off (though that didn't stop them from breaking things)
Prioritizing the needs of potential new users may bring you actual new users, but not prioritizing those of existing users may send some of them away. How do you know which group is bigger?
Sure, the group of potential users is massive but not all of them will switch. Meanwhile you're making software worse for people who actually use it and, at least for FOSS software, are usually your biggest advocates, part of the developer base, and one of the most important means through which new users are brought in.
Now you’re assuming that the group that would switch is bigger than the group that appreciates the tabs at the bottom. I doubt that the tabs at the bottom are the main reason people wouldn’t switch to KDE.
Not only this, but who exactly uses Konsole? It's certainly not grandma, who you set up with a KDE laptop. She's not going to know what to do with the command line, and even if she did need to use it for some weird reason one day under your direction, she sure as hell isn't going to open multiple tabs in Konsole.
The people using Konsole are already the highly technical people, and therefore probably not newbie users.
KDE had exactly that back in its 3.x era, actually. It had a first run wizard that allowed you to choose things like whether you open things with a single or a double click, and options were largely organised based on platforms with similar conventions (as in, it had options like "single click selects, double click opens (Windows style)"). It was remarkably friction-free actually, people could just pick the mode that they were already familiar with and that was that. It had all the good parts of "the right default" (i.e. the "right" default was always the one you liked best) and required exactly one click to configure.
Zorin OS takes this approach (and pretty far). At first boot you get to select Windows, Mac, Unity or Zorin style and it shifts a bunch of things around based on that.
It would be nice for KDE to have three presets: Windows, Mac, and Classic (= KDE).
The only "better" defaults are those that match what people already know, not necessarily because they're objectively better but because most people will already know how to use them. You literally can't get a learning curve better than "you already know it".
Konsole has had tabs at the bottom for about 25 years now (I don't recall KDE 1.x, but they were definitely there in 2.x). Who do you prioritize in a design? Everyone who already uses KDE, and expects them at the bottom, or a subset of users who might switch to KDE and expect them at the top?
More importantly, is the position of tabs -- especially one that you can change! -- like, a real, actual problem?