iirc using generics lessens type checking, and moves errors to runtime, but it might work as a wrapper to a flag lib itself

I have a weekend, I'll try to review this or work on harg..

What were you experimenting with golang.org/x/exp?

Not sure, it wasnt a direct import

I can't yet put my finger on it, but be aware, that multiple interface typing (interface{}.(type).(int)) will panic if the larger type is not found, under a if v, ok := .

if v, ok := resolves panic / gives ok value only on the last .(int). If anything before it is not found, it will panic.

edit: this seems to not be a problem in this source, it's the hacks with stdlib/flag, that made me feel it

edit2: I think I don't have much more to add atm, I'd rather go work on harg, or something else on my list.

jfyi generics are not the keyword here, what you/we are doing is implementing/using (generic) interfaces

I'd move flags to a separate subpackage (a subdirectory), this would most importantly isolate it, but also enable possible external uses.