Hmm. The way this would work for me is, I'd have pretty much the whole database interface managed by a Tab control on a main underlying form. In the rare event other forms need to pop up for dialogues, they always open modally, so they have to be closed before the user can interact again with the "main" form (with its tab control holding all pages & forms), and then there is an Exit Database button on that single form, so I can just Application.Quit from there.
Hopefully the only "several objects" that you allow your user-facing program to have open are Forms or Reports ... and never in design view. Couldn't you just use Application.Quit? Or is it because you are worried they are in the middle of editing a record and might run into your BeforeUpdate validation code?
I guess what I am saying is under normal circumstances, and all else being equal, you can simply use Application.Quit even if forms are open. You do not need special code to check if forms are open, etc.
I would recommend you not use Compact on Close. It is notorious for causing problems. And given a proper split database configuration, there is normally little to no worry about your users' front ends bloating in size.