In the recently published rev 1.0 of the AVX 10.2 spec there is a piece of pseudo-code at the very bottom of section 3.1.3. The IF condition there appears to make little sense, though. VL is derived from EVEX.b and EVEX.U (not EVEX.L'L). It therefore cannot form part of the condition here.
Further a somewhat related question (the option was likely considered, yet I cannot think of reasons why it may have been discarded): Why the use of EVEX.U here? In AVX10/256 configurations, wouldn't it have been possible to simply re-purpose the existing SAE encodings, simply re-specifying them to affect the register up to MAX_VL? I don't expect there's a significant need to have the separate 256-bit forms on 512-bit capable hardware. Since they don't raise exceptions, the sole difference is what they do to the upper halves of the registers. Yet if one writes 256-bit-only code, one won't care about those upper halves. (There would be some challenges for assemblers / disassemblers to sensibly consume / express things depending on context, but that is unlikely to be the only reason to use a separate encoding bit here. Hence the only possible reason may be performance / power consumption, when the upper halves don't need operating on at all, but merely clearing.)
Finally a minor remark: Considering that previously (prior to APX) there were (and in SDM still are) distinct EVEX.B (now EVEX.B3) and EVEX.b, it would probably be a good idea to spell EVEX.U uniformly (the U either uppercase everywhere or lowercase everywhere).
