Challenge: embody your very interesting views about exposition and the need to explain 'what is going on' in a document that can be printed on one side of A4 and that allows someone to start editing text with emacs/mg.
I for one would be interested to see how your approach pans out as an accomplished design.
I have a mental image of a stack of buffers being shown as a sheaf of overlapping 'cards'...
The practical reason is that learning Emacs is currently a long term project, and the serious study won't begin until I get around to buying a hard copy manual. I know my learning style. It's depth first. I'm bookish.
So, I'm developing an outline - a sketch of what Emacs actually is. To me it looks like AutoCad of 1991 with a less powerful graphic interface - AutoCad had screen menus which were a context sensitive text based menu system. The difference between that and the <handfull> of Emacs extensions I have seen is that AutoCad screen menus were persistent and had a dedicated slice of the "window" (right or left side). They paged and predated pull downs in the interface.
Anyway, the picture that is coming into focus is that what tutorials are teaching is not the language of Emacs (commands and eLisp), but the language of Emacs users (shortcuts).
Beyond that, Emacs command language uses a verb-noun structure. This is both a natural product of its Lispy origin and lousy for users.
[The following examples are fictitious]
Lisp thinking tends toward being about processes not objects. A programmer will create a higher order procedure <make f> contracted
procedure -> procedure.
Call <make buffer> and get <make-buffer>. Call <next line> get <next-line>, call <previous line> get previous-line. It's all nice and tidy from a programmer perspective.
It sucks for the user. The user needs a buffer. Is it <create-buffer>, <new-buffer>, <add-buffer>, or <make-buffer>?
Auto completion doesn't help. The user cannot easily conjure the proper demon. This is where object oriented conventions rule the field. If the user knows the kind of spirit, they know the first half of the spell,  and auto-completion is much easier. <buffer.next> <buffer.new> are more user friendly.
Just because from the perspective of the code <next-buffer> may be more akin to <next-line> than it is to <previous-buffer>, it is not akin semantically. There may be a natural language which uses prefix notation, but even if there is, few computer users speak it natively. When Emacs was a tool for a small community familiar with Lisp, verb-noun probably was not an impediment to learning its intricacies. Now it may be something a full fledged tutorial needs to be cognizant of.