I must admit I do not know what a RS is expected to do with it...

Nothing specifically, so I consider it part of the "MAY" section.

It's supposed to help RSes implement their own interface -- like providing a mapping for a dedicated toc button. That's the "efficient access" part of the definition. But other than skipping to the body matter when a book opens I don't know how much the links are even used.

We can't mandate reading systems implement behaviours or buttons, and otherwise there isn't a specific user-facing expectation. I haven't seen a reading system that lets users pull up the landmarks, for example, so it'd probably be hard to bump it up to a recommendation and also find implementations.

I must admit I do not know what a RS is expected to do with it...

Nothing specifically, so I consider it part of the "MAY" section.

O.k. I may be very picky, but I just may be the average reader: maybe it is worth adding (e.g., as a remark in parentheses) that this the "MAY" remark also applies to the landmark nav element, although that value of epub:type is explicitly defined in the spec.

But, again, I may just be too picky.

maybe it is worth adding ... that this the "MAY" remark also applies to the landmark nav element

I'm fine either way. I've added this for now:

It MAY provide users access to the links in the landmarks nav element [EPUB-33] and MAY use the links to enable functionality in the application.

If there exists another implementation that gives users direct access to the links we could always consider moving it to a recommendation.

I hear students say they wish publishers had a landmark at the beginning of a chapter that identifies all the essentials they should learn in this chapter.

You could probably do this with the learning-objectives or learning-outcomes semantics. It could also be done with ARIA within each chapter if there were better access to ARIA landmarks.

Merged this as we need a clarification. We can always review the requirements if testing shows they're unrealistic.