Update: a successful OFF control and a failing Current-crossing reorder I narrowed down the MusicKit issue with two standalone diagnostic runs on an iPhone 16 Pro, iOS 27.0.1 (24A446), using built-in audio. Both use ApplicationMusicPlayer, Repeat OFF, Shuffle OFF, and the same four distinct Apple Music catalog songs A–D. These are anonymized labels for the tested songs; I have not established that arbitrary songs behave identically. The goal remains to reorder the queue while preserving the selected occurrence, playback position, and playing/paused state, including uninterrupted audio when playing. The new comparison below concerns PLAYING A. Both runs use the same startup: install only A, play once, observe it, append B/C/D, explicitly keep Repeat OFF, then verify ABCD with A current and advancing time. The diagnostic has no Room synchronization, persistence, repair, replay, or seek recovery. Success: [A]-B-C-D -> [A]-D-B-C Failure: [A]-B-C-D -> D-[A]-B-C In both cases the app takes a mutable copy of queue.entries, removes D at index 3, inserts that same retained Entry, and assigns queue.entries once. The only mutation-plan difference is D's insertion index: 1 for ADBC versus 0 for DABC. A is never removed or reinserted in the local copy; no currentEntry setter is used. ADBC retained A, order, and advancing playback time through the approximately 10-second observation; audio and scrolling remained normal. Non-current SDK IDs changed, so this is not a claim of durable identity for every entry. DABC initially returned the expected four entries, the original A at index 1, and playing time 13.746/13.747 seconds in two immediate samples. Playback then stopped and the UI became unresponsive. No marker for the next scheduled 0.3-second sample appeared. Xcode Console reported an XPC service interruption. After Debug Pause, the client main thread was waiting synchronously for XPC inside MediaPlayer _establishConnectionIfNeeded / onServerAsync, through a dispatched main-queue block. The associated RemotePlayerService report at 2026-10-01 20:43:34 +0900 shows EXC_CRASH/SIGABRT and an assertion path: performQueueModifications:completion: -> performInsertCommand:targetContentItemID:completion: -> _qfa_performInsertPlaybackContext:atPosition:afterContentItemID:sectionIdentifier:actions:completion: -> _componentsForContentItemID: -> NSAssertionHandler / abort This framework exception path also appears in the earlier reports. The assertion message/arguments are absent. Both new runs logged "ping did not pong" during initial Play, then passed startup checks. They were separate runs; changing the destination also changes A's index and neighbors. I cannot attribute the cause solely to the numeric index. ALL with this same native DABC/A0->A1 operation has not been tested. Is this retained-Entry copy/assignment a supported way to reorder across the active entry without interrupting playback? If so, is there a known issue or fix for this assertion? Otherwise, what public operation and acknowledgement should be used to preserve the selected occurrence, time, and transport state while changing the full linear order? Filed as FB25016605, with the RemotePlayerService crash report and the successful/failed comparison logs attached.