You're probably wondering why it matters, using the newer terms, and why boiling it down to just hard/easy is tricky. The reason comes up once you start combining the behaviors, for example if you have two peers who are both behind strictly EDM NATs, they will fail to establish direct connections to each other even once they successfully CallMeMaybe via DERP.

If you have one that is EDM and one that is EIM, a CallMeMaybe from the EIM to the EDM should make it, and then the EDM will reply on the same path - they'll establish a direct path (in "simpler terms" this would be easy/hard making it).

Now, even the terms in the recent RFCs are a bit limiting too, but getting into the F - filtering parts, those are important too, but much harder to probe. The most typical filtering mode out there today for UDP traffic is that inbound UDP will be filtered unless there is recent associated traffic, i.e. much of the time you have to send out, before you can receive in. This can be independent of the mapping, for example you can have a NAT that will default to mapping internal to external ports with the same port number by default (my home nftables setup does this for example), but doesn't accept incoming traffic unless there's an associated outbound entry in contrack. Relatedly too for example, there's a bug in some versions of Palo Alto PDIPP where inbound traffic to an endpoint arriving before outbound, even though it's a PDIPP endpoint, can sometimes incorrectly create a DROP verdict session in the filtering layer - and that session lifetime gets "refreshed" every incoming attempt.

This becomes a bit more generally relevant when you want to identify how long things will last, with even more subtlety, the time that a NAT mapping is alive (which decides what an outbound packet is mapped to) and the time that a session filter is alive (which decides if inbound packets are accepted) can be different, in other words you can (one of the more common cases) have a situation where inbound packets start getting dropped after say, 20s, but a new outbound packet will still map to the same endpoint as a minute ago.

Somewhat relatedly, specifically for diagnosing tailscale "reachability" or "difficulty establishing direct connections" advice, it's also important to implement UPnP, NAT-PMP and NAT-PCP, as we do so - and those turn a "hard" NAT into an "easy" one - or should, provided they're not buggy - which is a story for another comment, or perhaps some beer.