The following features are reasonably easy to support and would be nice to have. Most of these were discussed at https://discord.com/channels/507304429255393322/566276937035546624/1058160427047059466.

• Ability to inspect properties of RenderMaterials. Additional discussion and comments: https://discord.com/channels/507304429255393322/566276937035546624/951253076361240616.
• Indigo should respect the checkSides parameter for block render contexts instead of never culling.
• Expose whether a specific side should be culled in the RenderContext (and cache it). This allows API consumers that do complex transformations to skip expensive transformations on quads that will be culled anyway, and without having to duplicate the caching logic. This will also nicely integrate with respecting checkSides.
• Should document that emitting quads from a QuadTransform is not supported.

TBD whether the AO disabling logic also needs to be integrated into the RenderMaterial before the quad transforms are applied.

Writing down this extra clarification from Pepper regarding the first feature:

There's a bit of strangeness with one of the material properties, noDiffuse, because QuadViewImpl has an extra field for it that I think is used for when a vanilla quad goes through FRAPI, but for the inspection to work correctly this field needs to be removed and the quad needs to use noDiffuse properly.
To be clear the inconsistency would arise from the fact that the quad's material would report one state of diffuse while the quad would actually be rendered with the opposite state of diffuse

It would be nice to have a sane way to access the current ModelTransformation$Mode inside of emitItemQuads. This should probably be added to the RenderContext. We could either extend the RenderContext with an item-specific sub-interface (ItemRenderContext extends RenderContext) and ask models to cast, or we could add the methods to RenderContext. Not sure what's the best option, but it will need to scale in case we want to pass more context in the future.

Numbers 2 and 5 were addressed by #2898.

Perhaps something to add to this issue is to remove texture indices. There has never been an implementation that has supported them and Grondag himself removed them in FREX because he realized that just making a new quad is much easier than supporting multiple texture indices.

Number 6 and 8 will be addressed by #3044.

Number 1 will be addressed by #3066.