Thanks Nigel.
I was gathering something like this, as I already saw some duples in our test system.
As it is a "mandatory" requirement in our architecture. I'm up to find a turn around for that.
My idea is to find the location to keep the "origin" of the account safe through any bounce. Of course this will require that the "origin" mnet_host is registered in the landing location, so a valid mnethostid can be found for this incoming user.
In this case we should keep a unique identity of a user across all our moodles, as long as he has a unique entry point that he will capture as origin.
In case we have no registered host for him, there would be a real issue to take the incoming host as reference. This would break again identity unicity and present a risk of duplication : say A -> B and C, B and C -> D, user a from A comming to B and registered as a::A, a comming to C registered as a::A, a comming to D through B registered as a::B, a::A comming to D through C would want to register as a::C. That not fits. So would we reject registration in this case.
There is another turn around in our case : as we have a unique "username" scheme, it would be easy to disable mnet_host caracterization on auth/mnet/auth.php§start_jump_session() so we default mnethostid to the first identified mnet_host for that username.
I still wonder what is the simpler to code...