Hi Sasha,
You could work around this by adding the prefixed and non-prefixed name, but that will produce inconsistent results depending on a prefix-aware set resolver, and risks duplicate records getting out of sync.
Maybe something could be automated on the server side (which in this case would mean RIPE DB), but I have the feeling that this would get ugly pretty fast (add a new qualified-member: attribute which auto-generates a member: attribute?).
Other than that, the only way I see is to first enable support for this in common AS set resolver code, and only support its use in objects once resolver updates are widely deployed. But that will take quite some time. It’s not terribly complex to add support to IRRD v4, but then we will need all operators to upgrade, and some are still on v2/v3. There will also be custom internal set resolving code in some organisations.
This would definitely be the cleanest way forward, but as you say it will take a long time (decades?)… I’m torn between the quick solution and the clean solution. Does anybody have better ideas? Cheers, Sander