Well what rule have KiCad broken with their GUI?
The short answer is, almost everything. From keyboard shortcuts, via menu structures, to alignment, naming and positioning of items like buttons in popup windows. Plastering windows with unstructured toolbars left, right and top. Unnecessary apply buttons, items only available via the toolbar and not also via the menu ...
What is one example of bad engineering?
Every single item where they deliberately or non deliberately went their own way. To name a trivial one, that is is hard to understand why they did it this way, look at the F3 and F5 keyboard shortcuts. The standard function for F3 ist to start a, or continue the last search. KiCad instead uses this to refresh the screen. While the standard for a screen refresh is F5.
GUI development is a lot about attention to detail. Getting the large stuff up and running, e.g. getting a window on the screen is easy. Getting the tiny stuff right, so users don't get annoyed is where you add quality to your GUI.
Once again, you can break the rules and make your own if you have the talent, mastered and won the game. I don't think the KiCAD GUI designers have the skills to pull that of.
If there is a rule for panning, it would be left click and drag like most graphics editors use, so every PCB package that uses right click and drag is breaking the rule. If KiCad used right click for panning, wouldn't that be breaking the "rule"?
The standard behaviour for left click is to select an object. If the object is not selectable, the left click instead activates the object's action (e.g for a menu item). The standard for right clicking an object is to select it and open the object-specific context menu. If you want to work on the drawing as a whole, like moving it, select it (that would be a left click on something clearly identifying the whole drawing, e.g, the background), and perform the action you want to do. There is an exception for the scroll wheel, which should always work on the current pointer position, skipping the selection.
It sounds to me like you want KiCad to just be a clone of another program that you are familiar with.
No, I just want it to be better. And as someone who maybe has to use hundred different programs in his job and at home, often only once a year, I want it to be consistent, so I don't have to learn yet another span of a diseased mind.
You know, I have been going through this discussion for more than 20 years again and again. I have heard every "argument" from the "but I know better", "style guide are for wimps" and "wouldn't it be great if" engineering crowd. In all this time I only met a handful of GUI developers who mastered the game and could get away with breaking the rules. They were all graphics designers, not engineers. In all other cases, sticking to the rules made a better program, compared to the crocked ideas and hacks engineers came up with.
Sticking to the rules doesn't make exciting programs, you can even call them dull. But that is still better compared to the stuff engineers would otherwise come up with.
If you were familiar with KiCad, then the other program would be the one with the "lousy engineering".
The one or ones not following the standards are the ones with the lousy GUI engineering. Unless it is a masterpiece. And I don't think KiCAD's GUI is even close to being a masterpiece.