I am trying to figure this out by going through the javadocs.

RenderAttachmentBlockEntity on its says this:

Dynamic model state data is separate from BlockState, and will be cached during render chunk building on the main thread (safely) and accessible during chunk rendering on non-main threads.

It doesn't say how, though.

By going into the same package, I found RenderAttachedBlockView which allows access, but its javadocs are even more confusing:

BlockView-extending interface to be used by {@link net.fabricmc.fabric.api.renderer.v1.model.FabricBakedModel} for dynamic model
customization. It ensures thread safety and exploits data cached in render
chunks for performance and data consistency.

While it seems obvious with a bit more Fabric knowledge, it would be nice if this would mention that even an implementor of FabricBakedModel needs to cast it's blockView parameter to this interface to access it.

Models that require Block Entity data should implement {@link RenderAttachmentBlockEntity}

I think that's missing "implement [...] in their related tile entity class".

Additionally, FabricBakedModel also refers to this subsystem in it's javadoc for emitBlockQuads:

@param blockView Access to world state. Using {@link net.fabricmc.fabric.api.rendering.data.v1.RenderAttachedBlockView#getBlockEntityRenderAttachment(BlockPos)} to
retrieve block entity state unless thread safety can be guaranteed.
param safeBlockEntityAccessor Thread-safe access to block entity data

This looks weird. Was there previously a separate parameter for this? Now it seems, the intended use case is to just cast blockView to RenderAttachedBlockView and the safeBlockEntityAccessor parameter is redundant? If that's the case, this should probably be changed.

If no one has any objections and my view on this is correct, I'd put in a PR with the necessary changes.