This is a bit subtle, WaitForIncomingMethodCall is basically a re-entrant activation of the mojo event loop. The current behavior seems to be that it also processes other events, so shutting down VrShell while it's waiting should set the variables to false via StopPresenting. 

It's unfortunately not very well documented, though one comment makes the re-entrancy assumption explicitly:

https://cs.chromium.org/chromium/src/mojo/public/cpp/bindings/lib/connector.cc?type=cs&l=203
      // Users that call WaitForIncomingMessage() should expect their code to be
      // re-entered, so we call the error handler synchronously.

I agree that OnSubmitFrameAborted or equivalent would be useful here to make this clearer.

Oh, you know what could happen: I used singleprocess mode (for debugging). In this case, it seems like mojo's reenterancy may suffer. It does not allow OnExitPresent to be received until sumbitFrame is finished. At least this is what I observed. However, I have to admit that I am running this code with M57 (146), assumed (probably, incorrectly) that M60 didn't change much in this area.

Interesting, even in single process mode I'd assume it would still use separate threads. The problem may be that the other side of the IPC connection isn't getting scheduled, not the reentrancy as such.

For the record, what build options and runtime options are you using for this singleprocess mode? Fixing this would be low priority, but would be good to understand what's happening.

It could be. And OnSubmitFrameAborted solves the issue anyway ;)
As to singleprocess mode: it is EXTREMELY helpful for debugging. I use Android Studio as a debugger and it works well with singleprocess Chromium. I had to do several relatively small tweaks (hacks, to be precise) to make it work, tho:
1) mojo/public/cpp/bindings/lib/binding_state.cc, BindingStateBase::BindInternal: I had to comment out the check "DCHECK(!router_);", for some reasons it fails in SP-mode.
2) content/browser/renderer_host/render_process_host_impl.cc, RenderProcessHostImpl::IsSuitableHost: removed the check "DCHECK_EQ(host->GetBrowserContext(), browser_context)"
3) content/browser/renderer_host/context_provider_factory_impl_android.cc, ContextProviderFactoryImpl::OnGpuChannelTimeout(): replace LOG(FATAL) by LOG(ERROR) there (don't actually remember why exactly that was an issue, though).
4) I've also added 'enforce_singleprocess' option into args.gn, that effectively forces to append the switch kSingleProcess switch to parsed_command_line in /content/browser/android/content_startup_flags.cc.

Unless I forgot something, this is pretty much it. I've also created a doc on how to setup Android Studio for debugging Chromium, let me know if you are interested.

Klaus, is there anything actionable here? If not, I think we should close this.

friendly ping? Klaus, should we close this bug or do you prefer to keep it open?

Let's close this out as WAI, this isn't an issue in production builds and needed a modified build using single process mode to reproduce. And even in that case, I think arguably that would be a bug in mojo scheduling.

Single process mode does sound potentially useful for debugging, but we should track that separately if it's something we'd be interested in enabling.