I set the keyboard shortcut for the Move Tool to a custom button (I picked the "V" key). so to reproduce this, do that. Then open a new document. Then use the custom keyboard shortcut, and it will indeed change to the Move Tool, BUT then will immediately, within milliseconds, change to the Shape Select Tool. Which of course then tells me "...you probably wanted the move tool." -- However, it DOES work fine when setting it to the default keyboard shortcut. It only has this issue when using a custom keyboard shortcut for the Move Tool as far as I can tell.
Bug confirmed! Application Version: Master
So I've further investigated this issue and it turns out to be rather interesting. The issue is that the V key is treated as a special key in krita, much like the control key or R key or Y key. However, unlike those keys, the V key changes the state of the tool selection because it acts as a temporary shortcut to the line tool when over the canvas area. When you bind the V key to a tool, it creates an issue where it loses the pointer to the previously used tool and decides to go to the selection tool. The quick (ugly) solution is to prevent the V key from being bound to. Since the V key has some hard coded behavior (switching to the line tool), it should not be able to be rebound for the time being. The long-term (better) solution is to remove hard coded attributes, temporarily lose the quick-access to the line tool, and try to rely more on the hotkey manager to do these types of behaviors. The even longer-term (best) solution is to provide more flexibility to our hotkey / tool system to allow for both modal hotkeys (permanent switching to different tools) and a temporary 'stack' based tool switch, which allows you to hold a key to use a tool and switch back after release.
The 'V' key isn't hardcoded: it can be reset in the canvas input settings dialog. It's a issue known that the shortcut conflict checker doesn't also check the canvas input settings. *** This bug has been marked as a duplicate of bug 329663 ***