I'm not comfortable with the scope of this change. I think this is a much more substantial expansion of the change than we should be taking as a PR to a previously accepted proposal.
My central concern here is that this is an expansion of when and how the DIXL validator is used by the runtime. The expansion of using the DXIL validator beyond just the debug layers raises concern to me because of the DXIL validator's uncertain future and known security weaknesses.
At a minimum I think we need to have some discussions to more clearly understand the motivations for these expansions so that we can appropriately prioritize and plan for support, maintenance, and associated risk.
This isn't attempting to change the proposal, but rather concretely define what the accepted proposal mentioned, which is there would be runtime control on validation. Note that the runtime will not have a built in validator, and by default it doesn't validate. An app has to opt in to the runtime validating, because they want to see the invalid state creation fail. And if they opt in, they have to provide a validator implementation.
This isn't attempting to change the proposal, but rather concretely define what the accepted proposal mentioned, which is there would be runtime control on validation. Note that the runtime will not have a built in validator, and by default it doesn't validate. An app has to opt in to the runtime validating, because they want to see the invalid state creation fail. And if they opt in, they have to provide a validator implementation.