Skillmon

@muzimuzhi imho, there is good reason to provide reordered versions of `\keyval_parse:...` functions. And due to the way those functions work (returning individual elements inside `\exp_not:n`) they can't possibly support...

> In general, we favour putting `` first for `\_:...` - the keyval stuff is non-standard as really these are `clist` functions :) I know the convention on argument ordering...

Even while working on the code, it sometimes helps to see the typeset results of the documentation around it to better understand it. Some explanations around the code are quite...

The issue actually is that it is assumed that every key property name contains a `:` by `\@@_define_code:n` which uses `\@@_define_code:w` in case there was a missing value in order...

Also, this is sort of fixed in current `develop`, but the fix there is wrong, imho, as instead of throwing the appropriate error that fix silently ignores the `ltkeys` names...

I can provide a fix that throws the errors if that's wanted.

This is arguably a borderline thing, as the real issue only affects the `ltkeys` properties but the problematic code is in `l3keys`. I really wasn't sure where to open the...

Please, no. Except for one (`.code`) this doesn't make any sense. And even in `.code` it's questionable. I'd much prefer the always-error solution, which is both easier to code and...

@josephwright about the question whether the consensus should be that the LaTeX2e key properties never raise a missing value error. (that's how I understood @muzimuzhi's last message) As a result,...

Done. Another question: `expkv-cs` has the `...` notation to collect any undefined keys encountered in an argument instead of throwing an error. Is that something I should add here as...