Heh, yep, we trod a lot of the same ground screwing around with this 
.
This one in particular is very difficult because the interface detail mappings are not in a dedicated container- they’re intermixed with the rest of the facts. My initial attempts used the top-level ansible_ prefixed values (not the un-prefixed ones under ansible_facts), which made it even harder because you have to make an intermediate projection of the names from ansible_interfaces to add the prefixes before you can dereference only those keys). Jinja’s rudimentary built-in select/reject (et al) require custom Jinja Test plugins to do arbitrary filtration- you can’t just give it an expression as you would with a comprehension, so you end up having to make numerous passes over the data- either with stored intermediate stages (verbose) or a giant chain of Jinja (verbose, inscrutable, and not-great-performance if done outside set_fact).
Last year, I hacked up some modifications to select/reject/et al that accepted Jinja macros in addition to test names- infinitely more powerful, but still doesn’t “read” nicely since you can’t just inline the expression as you would with a lambda or comprehension, and to do “near inline” macros requires a full template, not just a naked expression.
This time, I hacked up net-new comprehension filters that just accept expressions as strings that get compiled and invoked through a Python comprehension- they read almost identically to Python dict/list comprehensions, though quoting is still obnoxious. That’s the thing I’d like to move forward with. The current UX is still pretty crappy IMO, and I didn’t have enough time to do the concept justice in my talk, so I didn’t show them to anyone, but it did work surprisingly well.