Determine if elements should be removed from the toolbar during edit mode.

I was very very confused by this issue. Formatting really helps ;)

Per #2773601-54: Display "You are now in edit mode" prompt when user enters edit mode.

@tkoleary gave a very considered reply about the empty toolbar in the original issue's #38:

This ... goes to the long-view of the outside in editing mode. While it is true that in the current patch it feels rather empty at the moment and not having the toolbar takes the experienced Drupal user out of their comfort zone that will not be the case for long.

Very soon we will want to integrate the block place module with outside in, this adds another tab to the edit mode toolbar. Once we do that we need to take into account feedback on the block place designs that necessitates a select for all blocks on the page since some blocks may be put "behind" other page elements by the theme (for example an auto-play video block z-indexed under banner text). Since it covers the whole page, that select would need to be in the edit mode toolbar as well.

Moving on from there as we start to get into questions of block context in outside-in design feedback has also surfaced the fact that we will need a way to "contextualize" the page by "impersonating" a certain role or set of roles. Since this type of impersonation applies to the whole page also it could not be in the off-canvas tray (which by definition is focused on editing selected sub-sections of the page and not contextualizing the whole page) and would IMO also belong in the edit mode toolbar.

What about layout? Blocks and layouts initiative seems to be moving in the direction of a kind of "Panels IPE for core" if that comes about should the trigger for editing layouts in place exist in yet another toolbar (as it does now) or simply be another tab in the edit mode toolbar?

Finally we have quick-edit itself. It seems obvious to me that, ultimately, the experience we are looking for should be one in which clicking into edit mode also presents a toggle to quick edit the node itself, thus unifying all of the "in-place-editing" things in one mode. That toggle would naturally also live in the edit mode toolbar.

Now at that point it's not simply that we have an edit mode toolbar with a bunch of links and an administrative menu with a bunch of links and that's too much stuff on the page for the user to grok, it's that the types of items in each are of two fundamentally different classes. The administrative menu is just that, a menu, it contains links that bring you to other places. The edit mode toolbar on the other hand is not a menu, it is an application toolbar in the true sense of the word. Every button it might contain should perform an action that changes some aspect of the display of the page you are on and if it contains things that are links that bring you elsewhere that can only introduce confusion and ambiguity.

I could be wrong, but we can also look to how users actually interact with this and if not having the menu is a real obstacle or not.