Hi Patrick,
You raise a good point! Please also see this thread, which is related to the GitHub commit you cited:
https://community.acescentral.com/t/rethinking-working-spaces-for-amf
My understanding of the current spec is that it does allow your use-case (in your example, applying 3DLUT in WCS Y). But the proposal in that thread is to remove the ability to apply transforms other than a CDL in a working color space (other than ACES2065-1). This is why I wrote in that thread that I was worried that it would remove the ability of AMF to easily support certain use-cases.
The reason that I was not entirely opposed to the proposal is that CLF does support packaging more typical log-space based LUTs into a container that expects and produces ACES2065-1. So that would be one work-around that would allow implementation of the use-case you describe, even with the latest proposed change.
In other words, the working space conversion gets moved from within the AMF implementation into a step of packaging the original LUT from the production into an appropriate ACES2065-1 based LMT as a CLF. We could potentially add something to OCIO to provide that service, if people would find it useful (e.g. using any of the existing ACES CSC transforms and any of the 20+ LUT formats supported by OCIO).
This is an extra step, but as Chris wrote in the proposal, the benefit is that there is no uncertainty about what color space an LMT expects as input and output – it is always ACES2065-1, and thus follows the existing LMT spec from ACES 1.0.
Doug