It's not so much hiding the Form but clearing the reference (set frm = nothing) that is the key here. In the latest code snippet, I've removed the hiding part.
In my tiny brain this is how it should work:
If we're dealing with the default form instance, we need to start it up with DoCmd.OpenForm and because that is a Sub, it doesn't return form object reference back and it need to be closed with DoCmd.Close.
If we're dealing with creating instances of the Form, we need to assign it to the variable, that increases a counter for that object in VBA/COM layer but Access must be tapping into that to pass that reference to it's internal Forms collection. When that variable gets cleared (or goes out of scope) VBA/COM layer reference counter gets decreased, Access should clear that reference in the Forms collection and object gets released.
So if you step through the code when we set frm = nothing (and not hiding form first), form should disappear from screen because in debug mode Access internal processes can still run. At runtime can add DoEvents to lett Access do it's thing.
In our weird environments, Forms collection reference to that Form doesn't get cleared though, leading to Forms occupying memory and stacking up in forms collection.
Some very basic info regarding this in the following article (can't find anything more in-depth):
Create multiple instances of a form | Microsoft Learn
Initially when this was reported to us, we couldn't replicate it. We suspected that this will be related to Click-To-Run but at the time my machine was still on Win11 22H2. I think that after upgrading to 23H2 I've started seeing the issue but probably Office was upgraded at the same time.
We were hoping that this would be easier to reproduce by the community but sadly it is not the case.
We may need to create clean VM with just Office installation to see if we can reproduce it.