Yes, this is tricky. There was a lot of discussion around this with links to related usability tests I ran earlier in the year in issue 2148 tl;dr the default setting should be fixed to block

A fixed [docked to top] toolbar solution has several complications. Firstly, we break accessibility. I won't reiterate the discussion, as it's well articulated above. Secondly, we break things independent of accessibility - I ran user tests on something quite similar to this last year, and we discovered that disconnecting the toolbar from the point of action resulted in 100% user test fails.

@folletto and I discussed this in depth off-line, and Davide rightfully pointed out that the user tests referenced above were not identical, however, I believe that the cause underlying the friction is the same: there is too much visual disconnect between where the eye is focussed (i.e. on the block) and the location of the docked toolbar at the top of the page (which, even though it is contextual, and thus changes with each block, is too far away to be noticed)

Starting with the toolbar fixed to the block, and making the user explicitly dock to top should resolve the issue of discoverability raised here

there is too much visual disconnect between where the eye is focussed (i.e. on the block) and the location of the docked toolbar at the top of the page

I definitely agree here.

As much as I think it's better in the long term for a multitude of reasons to have it on top (no content covering, more extensible), I think the current approach is short-handing it: functionally effective, but not intuitive at first.

The problem I see now for someone not aware of that top bar are:

1. No initial learning — the page loads with something already inside the bar. This means there's never a proper transition from "empty" to "something", thus there's no awareness that area will change.
2. Mixed content — the toolbar is currently mixed with other icons, static, which again creates the expectation for that to never change.

It's notable that Office, that has a top-heavy UI so should be clear already "everything is up there", does a stark color and an animation when the otherwise static top bar changes:

In short, given the test results I think we should probably provide the above as an option ("Dock this") or if we prefer structurally the bar at the top, we should work to offset its discoverability shortcomings with color, animations, a better initial state, a guidance for first use.

Note: I consider "Docking" an option here even if in general I'm against options for something like this because we would still need to code it for when the component scrolls out of view. So there would be no maintenance "saving" as docking code would have to exist regardless.

I think it's important to get this default changed first. Then we can test and see. We can also then include any changes to the language we want and animation - I am all for that, but this issue should be about reversing the default. This needs doing sooner over later.

All tests are shouting right now that the default should be by the block, not the reverse. After we get this in let's test and iterate.

Just to note that the fixed [docked to top] toolbar doesn't necessarily breaks accessibility. It depends on the implementation. Quoting from #2148 (comment)

If all the UI becomes "inert" except the edited block and its toolbar, then the position of the toolbar in the source doesn't matter so much.

Aside note: the fixed [docked to top] toolbar has the advantage that keyboard navigation through blocks becomes way "cleaner", with way less tab stops. Instead, docking the toolbars to the blocks re-introduces lots of tab stops between blocks.
The introduction of "navigation mode" and "edit mode" discussed on another issue could help with this, but then I'd consider to make "navigation mode" the default.

@karmatosed the change was applied.

@afercia just to be super clear we're not ditching that as an option, it's more the current iteration is causing a lot of usability issues for people. We definitely need to go back to the drawing board a little and iterate on things - consider if we have a fixed toolbar what approach we have.

Thanks @jorgefilipecosta, for now closing this as we can then test and get feedback. Great thoughts everyone, I am closing but they won't be not included in any iteration.