> Reopen window, and reposition it where the user last placed it
Under Wayland, this is not the responsibility of the application, but the responsibility of the display server. You tag the window using the new toplevel tag protocol, and the display server will remember things like user position, size, always-on-top settings, and similar.
> Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?
It is neither possible to know where a window is nor to place it. That is purely up to the server, and under Wayland the goal is to tell the display server what it needs to know to create the UX the user would want - with a recurring focus on respecting user preference over having applications enforce the developer's preference.
But, it's important to note why it's made the display server's reponsibility: because the alternative was already broken under X11. Take a multi-window app that wants to open an old-fashioned "tool" menu. The application wants to place it to the left of the main window, which seems simple - until you realize it's not.
If the window opens fullscreen, the window would end up off-screen or on a different screen - okay, so we check if we're fullscreen and overlap the window instead. If the window opens near a screen edge or on a small screen, it might be too close to the edge - okay, so we also check if the left side of the main window is near a screen edge. Simple enough so far.
But then you run a tiling window manager (i3, awesomewm) and all new normal windows become tiles that pop up after predetermined rules, and random floating windows will be an error. Or you run PaperWM or Niri where the screen has an infinite horizontal size and so checking if a window is near an edge is always incorrect as the edge moves as needed. Or you run a VR window manager (we have those now!) so windows have not just X and Y, but also Z, pan, tilt and roll that the application does not know how to manage. Or you have a display server running on one of the OLED monitors that fold in and out like a recent CES lenovo laptop. Or...
Applications trying to micromanage their windows are effectively re-implementing a window manager that is always going to be making very heavy and wrong assumptions about the current window management paradigm and end-user preference. Instead of porting already broken duct-tape from X11, Wayland works on protocols that describe the intent properly - for example, by describing that an auxillary window is associated with the parent and should default to a placement to the left of it, rather than manually moving it.
(My personal opinion, unrelated to any project, is that traditional multi-window is a very fragile legacy design paradigm that doesn't make any sense, and that keeping operations to a main window and only using windows for isolated tasks - e.g., different workspace, file selectors, etc. - gives much better and more stable UX. Splash screens also no longer belong in a world of multi-tasking - just open the main window immediately, and if the app needs additional time to prepare, show the "splash" in the main window and transition later. That way, the user can multi-task and place the window instead of being interrupted by an application thinking they should cover up the center of the screen and randomly glitch windows in an out of existence.)
</walloftext>