Using an sObject as a Map key

Yes, that is the expected behavior. Behind the scenes, Salesforce is hashing the sObject. By changing field values, you change the hash. A better practice is to use the sObject ID as the key. This blog post explains some more: https://appirio.com/tech-blog/considerations-using-sobjects-in-sets-and-map-keys-in-apex

When planning to use an SObject as the key for a Map, be aware that it can sometimes behavein an unexpected fashion. If you are expecting to encounter a scenario where the SObject can be mutated (even indirectly, as done by an insert) once set as a key for this Map, you will lose the reference to the value for this Map for the SObject key that was mutated.

Doh, it appears it is the expected behaviour.

Uniqueness of keys of all other non-primitive types, such as sObject keys, is determined by comparing the objects’ field values.

Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values. This can occur if you explicitly change a field on the sObject, or if the sObject fields are implicitly changed by the system; for example, after inserting an sObject, the sObject variable has the ID field autofilled. Attempting to fetch this Object from a map to which it was added before the insert operation won’t yield the map entry, as shown in this example.

Source - Map Considerations