Reboot-free upgrade of an always-matched DriverKit dext

I have a DriverKit dext that implements a virtual SCSI HBA (no physical hardware). Because a bare IOUserSCSIParallelInterfaceController has no provider to match, the bundle ships two IOKitPersonalities:

1. Bootstrap — IOClass IOUserService, IOProviderClass IOUserResources, IOResourceMatch IOKit. In Start() it does SetProperties({NvmeOfSCSIHBA: true}) + RegisterService(), publishing itself as a nub.
2. Controller — IOClass IOUserSCSIParallelInterfaceController, IOProviderClass IOUserService, IOPropertyMatch {NvmeOfSCSIHBA: true} — it matches the bootstrap nub.

This loads and runs correctly. The problem is upgrades. Activating a higher CFBundleVersion via OSSystemExtensionRequest.activationRequest (in-place replace) always defers the old version's termination to reboot. The new version reaches [activated enabled] but never starts; the old process keeps running until reboot. From sysextd/kernelmanagerd:

kernelmanagerd  Dext … v15 … is being replaced and cannot be terminated right away
sysextd  delegate returns Error Domain=OSSystemExtensionErrorDomain Code=101 "…is being replaced",
         assumes responsibility for old version …, keeping old version 15
sysextd  turning the responsibility for termination of …, version 15 over to delegate
         (with uninstallation at the next reboot)
sysextd  a category delegate declined to terminate extension with identifier: …
sysextd  v15 terminating_for_uninstall → terminating_for_upgrade_via_delegate

Key observation: this defers even on a fresh boot where the dext was never opened — no app/daemon ever opened the IOUserClient, no I/O, nothing attached beyond the controller↔nub match. So it does not appear to be a "client still holds it open" / busy-state situation; the driver_extension category delegate declines the moment it's a replacement.

What I've tried:

• In-place activationRequest (replace): always defers to reboot (above).
• deactivationRequest (standalone): the request hangs — no delegate callback at all (waited ~13 min), even with no client open.
• Disconnecting all clients first (graceful Stop() that cancels its dispatch queues and completes async) does not change the replace deferral.

My understanding from the docs/forums is that the normal reboot-free replace relies on the backing device being disconnected/reconnected to quiesce the old dext (thread 677040). My controller matches a persistent IOUserResources-backed nub that never detaches, so there's no equivalent quiesce point.

Questions:

1. For a dext whose only provider is a self-published IOUserResources nub (no detachable hardware), is reboot-free replacement structurally impossible — i.e. is the Code=101 "is being replaced" defer inherent to this matching pattern?
2. Is the supported way to live-upgrade such a dext to deactivationRequest → (on .completed) → activationRequest rather than an in-place replace? If so, what makes a deactivationRequest complete in-session vs. defer to reboot for an IOUserResources-matched dext — and what would cause it to hang with no delegate callback? (Daemon's IOUserClient is closed; the controller's Stop() cancels its queues and completes.)
3. Should the dext itself proactively tear down the published nub (e.g. terminate the bootstrap IOService) before/at upgrade so the controller detaches — or does that just re-match the still-staged old personalities and relaunch the old version?
4. Is there a recommended pattern for a virtual (hardwareless) DriverKit HBA that needs in-field, reboot-free version updates, or is reboot genuinely required for this class of dext?

Environment: macOS 27 (Tahoe)