>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.
If you want to grow your user base: The latter.