There are many problems with Krita's shortcuts as they currently stand. The 3.0 shift provides an opportunity to re-think the defaults, as well as alter the configuration system itself. This is a head task for several things that could help Krita's shortcut system become an asset instead of a liability.
* Simplicity for newcomers. Krita's shortcuts have long been an area of confusion for newcomers. Commands should be mnemonic in English whenever possible, in addition to following standard CUA-style bindings (C-x, C-v, and so on.) Krita already does the latter.
* Effectiveness. Commands that are more common should be bound to letter keys and non-modifier keys. For example, mirror canvas horizontal should be M, because it is extremely common.
* Full coverage. This is not to say Krita needs to "copy what Photoshop does," but Photoshop does a good job helping you speed your work by binding tons of commands to the keyboard by default. [[ http://media.mediatemple.netdna-cdn.com/wp-content/uploads/2010/02/shortcuts3.jpg | Each and every letter key has a command, most with alt and control variants, and several function keys are bound as well. ]]
* Make available a standard, public reference. There should one definitive version, available on Krita's website, or prominent on the KDE Wiki.
* Internal design: either clarify, or redesign. Since Krita has forked KXMLGui there is an opportunity to redesign any aspect of the shortcut configuration system we please. Currently, the default shortcuts are set inside the C++ code and there is no general strategy for how it is supposed to be done, but the information seems to be duplicated in the XML configuration files, and some .action files as well. Moving shortcuts into external text configuration as much as possible would make it easier for users to create and share their own defaults.
* Tool command subsystem. PrimaryAction/SecondaryAction system is a huge pain problem. Within the code base this is separate from the shortcut system, but that is not something users need to think about - in fact, they should not even see or hear the terms Primary Action / Secondary Action, because they don't mean anything. If we write the configuration dialog again, it should provide options like, "What do you want control modifier to do when you are using the line tool?"