I think it fundamentally boils down to how you see the data. People that think in RDMS terms see the existence of the record as an implicit existence of the map

I think it fundamentally boils down to how you see the data. People that think in RDMS terms see the existence of the record as an implicit existence of the mapping key, since every record of a table has every attribute. If the record is not there, then it truly is None as in non-existence (no key present) but that operates at a different layer in our applications because the missing object doesn't have the methods or attributes of the class. It's a different class entirely! So in that sense the conflation issue with key => null vs no key at all is itself a mishandling, since it's operating on different classes of objects. This is what you call "paper overing" but I don't think it is fundamentally wrong, I think it's just a different way of reasoning about the data. It's also why I think the functional programming community prizes maybe monads more than the object orientated community. Functional programming is fundamentally about managing streams of data with functions that match up types, so the distinction between none and null matters because the data doesn't drag along it's methods from place to place.