Another behavior idea could be to allow windows that were shifted to clear space for the expanded Nav Bar to be shifted back if the Nav Bar is re-collapsed

An Access feature closest to your description is a "navigation form" (pictured below).  But it is one of Richard's "evil Access stuff," so he is unlikely to make an in-depth video about it, although he did make one on what he hated about it:

https://www.youtube.com/watch?v=byR1fza435g

A navigation form mimics the user interface of a webpage, where the user clicks a link on the menu pane to open a form.  It's basically just a subform whose source object changes according to the user's menu choices.  To create a navigation form, go to Create -> Forms -> Navigation -> Vertical Tabs, Left (the layout closest to what you described).

I watched the video and agree with Richard that the built in Access Menu and Navigation forms are nice but the use of sub forms in the Navigation form makes the coding too messy.

In my use case, my users often have more than one window open at a time and often resize them to fit a view size or to be able to see multiple forms at once. This sometimes creates a condition where my main menu form gets visually lost under other open windows. I thought that it might be a good exercise to build a capability like I described where the main menu is always around but doesn't get covered up by other windows and can be less obtrusive with the rest of the usable display space. It can also teach how to use resize events and DoCmd.Move with form sizing properties.

All your ideas are reasonable, but if the coding becomes unnecessarily complicated, you may need to forgo some of them.  Giving your users this kind of freedom is nice, but it is at the expense of whoever designing it.  Yes, I feel some of your ideas could be tough to implement: for instance, you want to let users freely move multiple forms around, yet you don't want forms to cover up the menus, etc.  That is not a trivial task.  If I were you, I would ask your users if they really need this.  Or don't ask them, just do it the simple way first -- such as with a tab control, which is what I used in my old job (see picture).  A tab control always keeps the menu tabs visible, but it only shows one form at a time.  This is a far simpler solution.  And if your users complain about not being able to move forms or use multiple forms, then you consider the more complicated methods.  P.S. A tab control is also one of Richard's evil Access stuff, unfortunately.

I think it actually may be easier than you think.'' Here is some pseudo code:

1) The width of the Nav Bar can be stored in a public variable myNavBarWidth As Long
2) A Public sub can be written that gets passed a form name "Public Sub adjustFormPlacement(frm as Form)" this will check the position of the form.''If it is located at a position inside the myNavBarWidth, then the sub will use DoCmd.MoveSize to move the whole window over to the right to start at the myNavBarWidth position, otherwise it just exits the Sub
3) In each form, in the On Activate and On Resize events, just add "adjustFormPlacement Me"''This will place the form at the right place whenever the form loads, reactivates, or is moved around.
4) The Nav Pane would be two separate forms. One compressed and one expanded.''The compressed version is just a narrow bar with maybe "Navigation Bar" in vertical text. The expanded view has all your buttons and other controls for navigation including a "<" control to compress
5) If the user clicks the compress button/control, the the expanded bar closes and the compressed version opens and changes the value for myNavBarWidth.
6) similarly, if the user double clicks the compressed Nav Bar, it closes and opens the expanded form and resets''myNavBarWidth
7) On each Nav Bar Load, a Sub can be written to cycle through the list of all open forms and execute "adjustFormPlacement rs!frm" against each.''This Sub could be tweaked to not only push the passed form out, but also move the form back in to abut the Nav Bar at myNavBarWidth''This could also just call an adapted version of adjustFormPlacement from step 2

It still sounds way too complicated.  It's not just the coding, but also the overall design that you need to consider.  Wouldn't it be simpler to just let the users move everything, *including* the menu pane?  That's what I would want to do if I wanted to move the menu pane out of the way.  I would move it myself to wherever I want, instead of having it moved for me.  That would be a much simpler design, and one that is used in many other programs that have floating menu items or option panels (see below).