I'll admit I'm a bit uneasy about mapping these APIs. The APIs and the behavior were never meant to be public. (That's why they seem so awkward). Perhaps we can add a disclaimer to them that it's an advanced feature, then focus our attention the proper solution upstream, which is to proxy the document attributes so they reflect the correct state when viewed from the tree.

I'm uneasy too. Rather than (only) marking them 'advanced' I think it would be better to indicate that a better solution is hoped for in the future and these methods may disappear.

I'll admit I'm a bit uneasy about mapping these APIs. The APIs and the behavior were never meant to be public. (That's why they seem so awkward).

I agree but right now they can be useful in some scenarios

Perhaps we can add a disclaimer to them that it's an advanced feature, then focus our attention the proper solution upstream, which is to proxy the document attributes so they reflect the correct state when viewed from the tree.
I'm uneasy too. Rather than (only) marking them 'advanced' I think it would be better to indicate that a better solution is hoped for in the future and these methods may disappear.

Sure, as soon as Asciidoctor core provides a better alternative, I will remove these methods and map the new ones.
I guess that Asciidoctor core will remove these methods in a major release (because even if they are not widely used, they are marked as "public").

Do you have suggestions about what we should add in the JavaScript documentation?

/**
 * Replay attribute assignments at the block level.
 * /!\ This low-level API will probably be removed in the next major version /!\
 */

I agree but right now they can be useful in some scenarios

I definitely recognize the need.

I guess that Asciidoctor core will remove these methods in a major release (because even if they are not widely used, they are marked as "public").

We really have no idea at this point.

They are public only because they haven't been updated to be private. Remember that prior to Asciidoctor 2, there was no delineation. So it's more that a decision just hasn't been made yet.

Do you have suggestions about what we should add in the JavaScript documentation?

I think it should be a very direct message.

This method belongs to an internal API that deals with how attributes are managed by the processor. If you understand why this group of methods are necessary, and what they do, feel free to use them. However, keep in mind they are subject to change at any time.

@mojavelinux Sounds good, thanks for your input! I will update the documentation to use a clear and direct message as suggested.