QPluginLoader::unload() returns false after deleting the plugin instance

Goal

I am designing a low-downtime update path for a small Qt 6 (C++) desktop application. The plan is to ship replaceable components as plugins loaded with QPluginLoader, unload the old plugin at runtime, swap the file, and load the new build — avoiding a full application restart.

Observed behavior

After calling deleteLater() on the instance obtained from QPluginLoader::instance() and processing pending events, a subsequent call to QPluginLoader::unload() returns false, and the library stays loaded. Qt's documentation states unloading is only safe when no objects created from the plugin remain alive, but it is unclear which objects count: the root instance, child QObjects, QML types registered from the plugin, and metatype registrations may all keep the library pinned.

Constraints

Target platforms include Windows, where a loaded DLL also cannot be overwritten on disk, so a failed unload blocks the whole file-swap strategy. The plugin registers custom metatypes and exposes one singleton-like object to the host.

Questions

1. Which categories of objects and registrations (instances, metatypes, QML types, translation files) must be torn down before unload() can succeed?
2. Is there a documented way to enumerate what is still holding the plugin open, or is unload failure effectively opaque?
3. Given these limits, is process-level handover (e.g., QLocalServer/QLocalSocket) the more reliable documented pattern for near-zero-downtime updates?