TL;DR: I went into detail why this specific issue hasn’t been solved yet. If you read it fully, you’ll understand the situation better. In short, your time estimation is most probably incorrect, three years ago Krita had one or two full-time developers and gained a few more only last and this year, and the feature is not used as often as you think (or other users don’t mind the issue), since I don’t get many questions about it doing user support, people ask for other features and issues more often. And it needs to be properly reported on bugs.kde.org (https://bugs.kde.org/show_bug.cgi?id=384529#c3 is not enough, in my opinion, it deserves its own bug report). And you can set up Increase and Decrease Opacity shortcuts in Configure Krita -> Keyboard Shortcuts.
It’s probably because they use the HSX color model, which is not actually a proper color model but an alternative representation of RGB.
The reason you got only less than constructive responses is because even though you said that
your post sounds extremely condescending and aggressive. Maybe you didn’t intend it that way, maybe you’re just frustrated and didn’t think of it much, maybe you haven’t expected meeting actual devs here. (Although, tbh, there is not much difference - when I was just a volunteer before I was hired, I was getting upset too when someone was coming to reddit to just rant over Krita).
I guess it would be beneficial to talk about why this specific issue isn’t solved yet. There are multiple factors.
First of all, while for you this feature is crucial and the issue you’re experiencing breaks your workflow, it’s not actually as common of a problem as you think. I am doing user support on reddit for nearly two years now and I maybe got a question about those color hotkeys once or twice, while I got a lot of questions about Colorize Mask colors getting shuffled when the user has over 16 colors and then they set one of the colors as transparent. And I still forgot about this issue (even though I thought it’s important and we need to fix it quickly) because Transform Tool crashes were more important than that. (And I’m deep in resource rewrite anyway, and Krita team was mostly fighting with building issues and serious regressions on the last few months).
You might see this feature as essential, but if you think it through, you’ll notice that Krita has thousands of those little features here and there. We now have 400-500 bugs and similar number of wishes on our bug tracker. The sheer amount of it is overwhelming; and we really have not enough developers to fix them all quickly. Some of the bugs and issues are fixed quickly (crashes, data loss, regressions (something worked and in the last release it stopped working), high priority bugs in features or tools that are constantly used), some of them needs to wait.
Another factor is that those three years ago that you mentioned, Krita team had one, maybe two full-time developers (I’m not sure when @boud was hired full time). Now we have 5 full-time and 2 part-time, but note that three of the full-time ones were hired throughout last year and the part-timers were hired this year, only a month or two ago. Before that, there were @dkazakov and @boud, at some point Jouni joined them, not sure when and for how long. Other than that, there was a bunch of volunteers. Unfortunately, there is one more difference between Krita and Photoshop that you haven’t mention: Krita’s budget is way smaller. We do want to have software that contains no bugs and all features work great, we do work towards that goal - but this goal is not reached yet.
Another factor is time estimation.
I’m sorry, but if you don’t know Krita code and architecture, your coding time estimation might be very far off. Even I, after coding on Krita for a year, don’t really trust my own time estimation too much and ask @dkazakov or @boud if I’m right. @dkazakov did fix 6 bugs in one day at some point in the past, but even he usually spends days on one bug. This one might be easy, but if my suspicion is correct, it would require some juggling of color spaces, specifically a perceptual one, and it might be difficult, impossible or just not worth it, since the perceptual model (YUV, YCrCb, or something similar, I’m not an expert) doesn’t have a Hue ring like HSV and other HSX models have, but just two values that create a square, not a circle. So it might turn out to be even less usable for the end user.
Another factor is the fact that it wasn’t properly reported, or I haven’t found it. There is a wishlist item here: https://bugs.kde.org/show_bug.cgi?id=384529 but it’s only mentioned in Comment 3 (https://bugs.kde.org/show_bug.cgi?id=384529#c3) and the wish asks for selection of different HSX color models, which might or might not fix the issue you’re having. Note: forum posts are nice and all, but if it’s not on the bug tracker or in a phabricator task, it won’t be remembered. Having it in a wishlist item decreases the priority, and having it in a comment makes it basically invisible (note that the title doesn’t say anything the specific issue you’re having).
(Another side note: anyone reading this, please make a forum post about a new feature you’re thinking of, do not report them on the bug tracker unless you’re asked to do so by Krita developer or user supporter. There are reasons for that, but I don’t want to digress too much).
That sound like a good Python plugin idea, quite easy to implement. If you are a developer, you can try it - you’ll get a lot of help here. Or ask someone to do it. It should be 30 minutes of work And maybe an hour of screaming with frustration on restarting Krita every time one makes a little change in the code…
Also there is a shortcut for changing the opacity. There is “Increase Opacity” and “Decrease Opacity” in Configure Krita -> Keyboard Shortcuts (it changes it by 10 percentage points). You can also change it quickly in right-click brush HUD menu.
Actually, the color hotkeys are probably possible to be implemented as a Python plugin as well.