I am testing an audio-only MediaDeviceExtension on an iPhone 17 Pro, with Xcode 27.0 (27A266a). The same application build reproduces this on iOS 27.0 (24A437), after a full reboot, and on iOS 27.0.1 (24A446). The extension advertises .realtimeAudioStreaming, one stable device UUID and a reachable, nonzero-port endpoint. It connects to the receiver before reporting activatedDevice. From startRealtimeSampleDelivery(session:), it calls AudioServerPlugInRegisterMediaDeviceExtension. The plug-in exposes one output device with the same UID and kAudioDeviceTransportTypeRemoteStreaming. The driver interface lives for the extension process and is registered on each delivery start. Stop/deactivation closes the transport and stops forwarding samples; it does not terminate the extension or register a null interface. Reproduction: start audio, select the extension's route, confirm audio flows, switch to iPhone Speaker, then reselect the same route while the source keeps playing. First selection works; subsequent selections briefly deliver audio before reverting to Speaker with AVOutputContextDeviceConnectionFailureReasonMDERouteRevertedToLocal. Pausing the source before route selection, waiting five seconds and resuming worked repeatedly in the same extension process; uninterrupted reconnection is the required behavior. The normal test uses Spotify and a separate receiving app. A diagnostic control on iOS 27.0 also reproduces first-success/reconnect-failure using a native AVAudioPlayer PCM source and a separate Mac receiver that counts/discards the samples. That control has no Spotify, DSP processing, local receiver playback session or same-phone transport endpoint. Stored device logs on 27.0.1 show two failed reconnects: Observation Reconnect 1 Reconnect 2 System policy chooses fallback before startRealtimeSampleDelivery 11.103 ms earlier 26.956 ms earlier MusicVAD reported present after fallback decision 364.019 ms later 409.215 ms later Driver registration result OSStatus 0 OSStatus 0 New captured frames before system stops delivery 52,224 47,104 Time from fallback decision to Speaker selection 1,507.218 ms 1,507.904 ms The policy logs identify the active, non-video source as not supporting the extension's protocol, then attempt AirPlay fallback. On the first successful connection, MusicVAD is already present and the policy explicitly permits that same source. On reconnect, successful driver publication and subsequent I/O do not cancel the earlier fallback decision. Transport reports show zero drops and socket errors; StartIO/StopIO counts balance, the stream-active setter is honored, and callback session IDs match. No registration interruption is captured during these attempts. Creating a media device extension directs publication from startRealtimeSampleDelivery. The registration API describes the interface, UID and transport requirements, but I have not found the supported teardown/re-registration contract for this retained-process case. Between stopRealtimeSampleDelivery / deactivation and the next delivery start, should the extension retain and re-register the same driver interface, recreate it, or withdraw the audio device through a documented operation? How should an audio-only extension using the documented publication callback ensure the system's compatibility check waits for its audio device? Is there a supported readiness or completion signal that the implementation must provide? The evidence identifies an ordering difference; I am not assuming it proves an OS defect. Guidance on the required lifecycle, or a reference implementation demonstrating uninterrupted reconnects, would help isolate the remaining driver-versus-system boundary.