You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable:
In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown which should not have been there - and were not there - when the units were first loaded.
Given that SystemD can't reliably handle explicit use of _netdev, I'd say it has no hope of reliably doing any sort of "just works" inference.
And I'm not a systemd hater. I very much prefer it to the sysv mess that existed before. The core systemd project is solid. But there is no overall vision, and the scope creep resulted in a Cthulhu-like mess that is crashing under its own weight.
I'll refer back to the story of Van Halen's "no brown M&Ms" contract term and the reason for the existence of that term and ones like it.
"Documented features should be reasonably well-documented, work as documented, and deviations from the documentation should either be fixed or documented in detail." is my "no brown M&Ms" for critical infrastructure software. In my professional experience, the managers of SystemD are often disinterested in either documenting or fixing subtle bugs like the one GP linked to. I find that to be unacceptable for critical infrastructure software, and its presence to be indicative of large, systemic problems with that software and how work on it is managed.
I really wish SystemD was well-managed, but it simply isn't. It's a huge project that doesn't get anywhere near the level of care and giveashit it requires.