@Jdlrobson please edit this task as you see fit. It is very much a rough first pass based on what we talked about briefly offline on 5 November.

when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy)

Render things in the area which the menus occupy

the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient?
is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode)
do we always want to collapse the sidebar or are there situations where we dont want to do this?

Our initial requirements would just be a call that could hide/suppress the sidebar so that the VE could reserve that space for EditCheck. VE would be responsible for restoring the sidebar after.

while the right rail is collapsed is it possible to pin anything there via user interaction (my assumption is no)

No

Render things in the area which the menus occupy

Oh I misunderstood this then. Glad I asked! I thought you were rendering edit check in the surface area for VE. So you would need the HTML container that the page tools is currently in to be empty but present in the DOM so you can render inside it?

@ppelberg the web team discussed this yesterday and think that it can be declined, as it is our understanding the editing team found a way to do this without our assistance. Is that your understanding too?

We did do it (in a somewhat-hacky manner). The main drawback of our approach is that we're outright hiding the sidebar, rather than properly collapsing it. I.e. if someone has things kept in the sidebar, they are gone until they leave VE.

The notional thing that a proper API might provide for us would be collapsing the sidebar items back into their menus temporarily (and without storing the preference), to preserve access to their contents during an edit. In particular, someone who's editing might very well want to tweak the appearance menu and see how e.g. a table they're making looks with the largest possible font-size. (There's also a few things that someone might potentially want to look at in the tools menu, but that's all accessible by opening a new tab.)

Thanks for the update! I swept it back into our backlog. Let's talk about it in our next editing/web sync!

Next step(s)

Per offline discussion with @medelius, @HFan-WMF, and @Jdrewniak today, the Editing Team is going to assess the extent to which we are in a position to implement the Requirements the description holds.

Note: were the Editing Team to take on this work, the Reader Experience Team would be in the position to determine the viability of a given technical approach (read: reserve right to +2 any code).

1. when we say "use the space" do we mean render things in the area which the menus occupy (or do we mean within the content area that hiding the menus occupy

We're currently removing the menus entirely, and rendering things into the area they were taking up by expanding the width available to the VisualEditor. This means it's all within the now-expanded content area.

We accomplish this via .ve-editcheck-available .skin-vector-2022 .mw-body .vector-column-end, .ve-editcheck-available .skin-vector-2022 .vector-pinnable-header-pin-button { display: none !important }

2. the request asks for a way to identify current state, could we expand this with use cases. Would a method that cleared out the sidebar in the event it is occupied be sufficient?

I don't think we care about the current state, per-se. We want to make a call that tells these to get out of our way, and then later make a call that tells it that menus can return if they need to. That can all be done without knowledge of the state in our code. (And is better that way, because it means we don't have to pass that state around internally.)

3. is restoring the sidebar state the responsiblity of the caller or the new method (e.g. perhaps it is based on a condition e.g. edit mode)

I think it's simplest if restoring is handled by the caller -- we can tell it to hide on initial setup, and tell it that restoration can happen on teardown.

4. do we always want to collapse the sidebar or are there situations where we dont want to do this?

Currently we want to collapse it whenever edit checks are potentially present, because they need a sidebar and doubling-up sidebars is a problem for content. We already have the logic for this implemented, and only apply our hack when edit checks could be present.

We've discussed hiding the sidebars in general during editing, but haven't gone ahead with it so far.

5. while the sidebar is collapsed is it possible to pin anything there via user interaction (my assumption is no)

No. Stopping people from pinning things there in this mode is the entire point.