Ok, so apart from the technical aspects: We can handle right-click actions and - depending on context and clicked “object” - display different context menus. Can’t we handle a middle mouse button click then?
And we don’t let you remap which context menu appears, or which button makes it appear, or anything about how the mouse as a pointing device behaves. And that’s before we start on all the other things about mouse handling that are abstracted into code that we don’t directly control like “drag and drop”.
If there was some incontrovertible and universally accepted meaning that pressing mouse button 37 should have in some context, then it would make sense for everyone and everything to have coded that behaviour for it. But there isn’t, and really, at that point it’s no longer actually a “mouse” in the UI sense, it’s some marketing abomination with an ear grafted on its back, that almost nobody has really cared enough about or seen enough value in to actually make more generally useful. It’s got too many buttons to be some recognised flavour of generic functional mouse, and it presents the extra ones as basically glorified GPIO pins with no predetermined function, and not in the already established idiom for things with lots of buttons like that one with 104 of them just to the left of it which your other hand normally stays on.
So I’m confused about why we’re still circling this particular drain hole, because it’s a bit like asking “apart from the technical aspects, why can’t my car fly?”. How do you separate “because it was never designed to” from “the technical aspects”?
Sure you can try to forcefully retrofit wings to it, but mostly that’s just going to make it mostly unfit for both purposes.
Yeah, I probably didn’t articulate well enough what my (limited) understanding of how an event like clicking a mouse button is being handled and how that event can be mapped to something else. Certain events we can (and should) prohibit from being mapped, I understand that, but I think that it should be possible in the Configure Keyboard Shortcuts dialog to handle the event of the middle mouse being clicked and assign that to the function of making a cut. And, yes, using the context menu example was not a good one.
except for that pesky little bit where that’s not only not our code, but mouse events don’t go anywhere near it to be handled by it. Let alone how you would figure out and handle which contexts should have it act like that button and which absolutely should not.
ergo “technical aspects” : )
right-click 
on the desktop and choose configure desktop
under the mouse tab add an entry for the middle mouse button and assign the action as standard menu.
now you have the right click menu activated by the middle mouse button.
Ok, guys, I give up. You convinced me that it is not trivial and there are many more reasons why we shouldn’t go down that road. I’ll stick to Keyboard Remapper for the time being if I want to assign an action to a mouse button.
I didn’t ever get to whether or not we should : ) As I noted much earlier, I can sympathise with the dreaming, but the question of should is kind of moot without a realistic mechanism that means we in some practical way could.