That did not strike me as odd before, but why we do we need to call out the unability to "monitor the list of available presentation displays for the entire duration of the controlling browsing context" in step 6. of the getAvailability algorithm?

This concept does not exist in the start algorithm. In start, I think this is captured by the fact that the algorithm to monitor the list of available presentation displays will simply create an empty list of available presentation displays.

Following the same logic in getAvailability, given an empty list of available presentation displays, step 9. correctly returns a PresentationAvailability object whose value is set to false if the list of available presentation displays. In other words, step 6. seems useless to me.

A user agent may let users disable the ability to monitor the list of available presentation displays at any time. If that happens and there's already a list of available presentation displays, I would expect the user agent to run the monitoring algorithm once again (with an empty list of presentation displays) in the background. I'm not sure this needs to be made explicit in the spec given that we leave it up to implementers to run the monitoring algorithm again whenever they want, including "never" if they so choose.

On removing step 6: That seems fine, but the step is not useless. I would want to adjust the language in the "monitor" steps to set the list of displays to empty and abort if monitoring is disabled, effectively moving the step to a different list of steps. That seems like an editorial improvement.

On disabling monitoring: From a user experience point of view, agreed it would be better to run the monitoring algorithm with an empty list, so that existing PresentationAvailability objects get a change event. Otherwise, a page may believe there are available display, and its attempt to start presentation would reject with NotFoundError.