Exploring the bug, it seems that rpc.idmap on the server maps a UID to a name for RPC, and on the client does the reverse. The only earthly reason for this is to get the server/client names straight. Unfortunately it isn't applied on all operations - specifically, not when you open a file - and the discrepancy being seen is because of that. (I have to say that regardless of whether you think idmap is doing the thing it's supposed to do the resulting behaviour is just stupid, and incredibly unuseful - if you have perfectly matching IDs then there's no need for a name/id translation at all and if you don't this doesn't solve the problem.)
On Fedora they no longer use rpc.idmap, they use nfsidmap (a different kernel comms mechanism) - I don't know whether this is used in more cases or what but it's possible it behaves differently.
Exploring the bug, it seems that rpc.idmap on the server maps a UID to a name for RPC, and on the client does the reverse. The only earthly reason for this is to get the server/client names straight. Unfortunately it isn't applied on all operations - specifically, not when you open a file - and the discrepancy being seen is because of that. (I have to say that regardless of whether you think idmap is doing the thing it's supposed to do the resulting behaviour is just stupid, and incredibly unuseful - if you have perfectly matching IDs then there's no need for a name/id translation at all and if you don't this doesn't solve the problem.)
On Fedora they no longer use rpc.idmap, they use nfsidmap (a different kernel comms mechanism) - I don't know whether this is used in more cases or what but it's possible it behaves differently.