My understanding is that the app must be fullscreen, and the user can always escape fullscreen and pointer lock with the ESC key. I guess there is a risk that the browser could hang in that state, though, which makes it even more important for Mozilla to focus on their browser's stability.

> My understanding is that the app must be fullscreen, and the user can always escape fullscreen and pointer lock with the ESC key.

It is similar in other windowing systems. But, but...

You are in fullscreen mode with a pointer grab. An important window pops up over the full screen: "10 minutes of battery remaining". What is the state of the grab while this window is shown? Will the code holding the grab be notified of this window? How will the pointer grab behave while the pointer is over the other window? Will the other window able to gain focus with a click? Should windows over other fullscreen windows be allowed at all? In general, how will the pointer grab reflect on the OS windowing system's pointer grab?

Past windowing systems tells us that it is extremely difficult to get all this right if the code doing the grab and doing the window management are the same code, something that is not going to happen with web apps.

Since there's a good chance moving the mouse is moving some gun around in 3D space rather than any visible pointer, the answer should be the same as for normal 3D games: to use the pointer or other windows, you must press ESC.

As mentioned on a comment a little below, this was designed with security in mind. Requesting mouselock can only be done together with requesting fullscreen mode, which is only possible in response to user input (like pressing a button) and after that requires explicit authorization. Afterwards, pressing escape will always leave both fullscreen and mouselock.