It looks like when I had to rewrite that part of KeeFox into Kee I forgot that it was the browser-addon side of things that is responsible for ordering the results to prioritise those with the correct realm. I may be forgetting some details by now but I think that the intention with Kee 2.0 was to retain the same behaviour of KeeFox, which was, at least originally, to include all entries with a matching domain/hostname but order the results by how accurately they match, taking into account other factors such as the realm. This way, the best match (with the correct realm) should be auto-filled but other close matches are available for situations where the realm is changed by the website at some future time.
It looks like that never got implemented in Kee and I can’t see any issues to track the work or code comments to explain why that’s not been done.
I’ll have a think about whether the sort-only approach is the right one before rushing into any implementation - it sounds like this might not actually help your use-case anyway?
You might have more luck with the URL matching control described in the recentish release notes: Release notes - KeePassRPC 1.8.0
PS: Sorry about that KeePassRPCService.cs code - there is no reason for that to be two different loops since they are supposed to be doing the same thing (ignoring the realm entirely so that Kee can make the decision at a later date). I have to keep the realm parameter for backwards compatibility but it should be made a lot clearer what’s going on there - I probably modified two loops that used to do something different over many years and never noticed that they ended up the same!