This seems to be the crux of the problem. Restated, you find match ergonomics lack the external consistency required for your intuition to guide you to a correct solution. In effect, you're arguing the feature works like 2015 modules--while guided by simple rules, the implications of those rules are non-obvious.
I've encountered this frequently while writing or reading heavily functional code. Scala's implicit arguments and Haskell's "point-free" notation are especially confusing, because they rely a great deal on what's not stated. My intuition says "what you see is all there is", so I often end up going down a rabbit hole of increasingly bizarre error messages. It's especially demoralizing when I find that simple-looking code is filled with unstated assumptions.
I'm interested in knowing which patterns you find surprising. Even better (though it's a lot of effort), would be a screencast or writeup that demonstrates you running into surprising behavior while editing code. If there are particular patterns that cause trouble, these could be used to improve compiler guidance, especially adding lints that offer guidance to bring non-obvious elision to the fore.
I used to work in a bikeshop when I was a kid. I asked the owner to hand me a wrench. He threw it to me, but it slipped and ended up traveling straight at my head. After catching it, I looked up to see anguish painted on his face. He couldn't believe what he'd done. A few years later, I played a practical joke with a knife that could have cut off someone's finger, and found myself in the same position--appalled and filled with regret.
Every tool is dangerous, particularly the ones with safety features. My experiences reinforce the adage "Safety isn't a quality; it's a habit."