Oh, right: dict (i.e. order doesn’t matter) in the capable.core212.logical filter vs. list items (order does matter) in the utoddl.logical.logical filter. I glided right over that difference and didn’t even notice on first reading. Oops.
Also, naming things is hard™. I had a working stand alone logical filter before collections were a thing, then leaped - perhaps prematurely - onto the collection bandwagon as soon as that became practical. I ended up with a collection with a stupid name containing only the one filter of the same name. Similarly, I suspect “core212” as a component in your FQCN is going to be of dwindling interest rather soon. But I guess that’s partly the point.
I will say this: Your code is way cleaner than mine, and that’s only partly because mine includes data promotions. Mine is also about ⅓ debugging print statements. There’s a reason my code looks like it was written by somebody who learned BASIC in the late '70s and hadn’t really grokked Python when he started writing Ansible filters. But since it works and life is short enough already, I haven’t prioritized cleaning it up.
To @jon-nfc’s point, which paraphrased is, “Why embed logic in data outside of the Jinja provided methods?” @kks already mentioned Jinja is geared toward text, although Ansible is much smarter about interpreting Jinja output as data than it was at the time utoddl.logical.logical (ne logical) was written. Likewise the number and quality of Ansible filters etc has vastly improved since then. Even so, for me it comes down to, “Which expression of the data and logic would I rather maintain?”
If anyone finds logical (any variant) abhorrent, then by all means don’t use it. But for those intrigued by the idea of data altering itself, then I invite you to take a look at the polymac filter!