Unfortunately, I don’t. This is why I’m so enthusiastic about the idea that “packaging should include creating standalone applications” - the import-chasing machinery used by PyInstaller and other installer makers, seems quite fragile, and rooted in a time when package dependency data was very much in its infancy and nowhere near as reliable as it is now. So there’s a big cultural gap between the people writing tools to build application installers and the packaging community.
I suspect there’s also a minimalist “optimisation” motivation involved here - import chasing can strip out unneeded chunks of a large library, reducing the final application size significantly (think something like pywin32, where only a tiny fraction of the functionality might be used by any given application). But it also increases the fragility, if the application uses tricks like lazy loading.
This is precisely the audience that aren’t supported well by the existing console entry point based solutions used in “packaging” (as opposed to tools like PyInstaller). So yes, I think you have a valid use case that’s currently badly served by the Python packaging ecosystem. Sorry there’s no better news to offer here.
(One thought, BeeWare are apparently doing interesting things in the application building area. I’ve not looked into what they do myself, and it’s possible they’ve also adopted the import-chasing approach, but it might be worth checking them out).