I have filed the bug report(FB23174154) and the feature request(FB23174302), thank you.

Thanks for your infos. I'll file an enhance request and provide more infos about my app in the request. For my app, if the pushwindow api could support volume that'll be perfect. Interestingly, if user open immersive space in my app, I could precisely control the placement of 3d content after the menu window closed.

The reason I considered using a volumetric window for the menu is that the current defaultWindowPlacement APIs for regular 2D windows do not seem to provide a way to replace a 2D window with volumetric content in the same spatial position. For that reason, I was thinking that if both the menu and the 3D content lived inside the same volumetric window, the transition from menu UI to 3D content could feel more natural and avoid the placement jump between a 2D window and a volume.

Thank you for the detailed explanation. After doing more testing, I think I found that the main issue in my case is not only the initial placement offset, but the relationship created between the volumetric window and the reference 2D window when using defaultWindowPlacement(_:). When I open the volumetric window using defaultWindowPlacement(_:) relative to an existing 2D window, the volume appears to have an initial binding to that reference window: If the user moves the reference 2D window, the volumetric window moves together with it. If the user closes the reference 2D window, the volumetric window is also closed. If the user manually moves the volumetric window once, this binding appears to be permanently broken for that window session. After that, moving or closing the original reference window no longer affects the volume. This behavior does not happen when I open the same volumetric window without using defaultWindowPlacement(_:). So my follow-up question is: is this reference-window binding an intentional part of the defaultWindowPlacement(_:) design on visionOS? In other words, when a window is placed relative to another window, should developers expect the new window to remain associated with the reference window until the user manually repositions it? For my app, I eventually chose a different transition approach. Instead of using defaultWindowPlacement(_:) to place the volume directly relative to the original 2D main menu window, I now use a temporary loading utility window as an intermediate step. The flow is: From the 2D main menu window, open a temporary loading window using defaultWindowPlacement(_:) with the utility panel placement. After the loading utility window appears, dismiss the original 2D main menu window. Open the volumetric window without using relative defaultWindowPlacement(_:), allowing the system to place it automatically. Once the volumetric window is ready, dismiss the temporary loading utility window. In practice, this gives me a much better result. The temporary loading utility keeps the transition visually understandable, while the volumetric window is placed by the system in a position that feels closest to the original 2D window’s location from the user’s perspective. It also avoids the reference-window binding issue between the original main menu window and the volume. The main reason I moved away from using defaultWindowPlacement(_:) directly for the volumetric window is that it does not provide the one behavior I need most: replacing or transitioning from a 2D window to a volumetric window while preserving the approximate spatial center. The available semantic placements such as trailing, below, or utility panel are useful for secondary windows, but they do not work well for this particular 2D-to-volume transition. I’m no longer blocked, but I wanted to share this observation and confirm whether the binding behavior is expected. If this is not the intended behavior, I can file a Feedback Assistant report with a minimal sample project and screen recording.