Maybe due to your conciseness and my basic Enlgish I have doubts on the second part of your post: I'd like you to expand a bit

> Depending on $ret is a mistake, its a sad part of that api

The usage of checking $ret (explicit or implicit) aka the return value of the GetOptions call is a well established behaviour. What to do better? Should I wrap into an eval block? Iirc I tried but no $@ was set in case of errors.

> Sub::Getopt::Long is a wrong namespace prefix

I never understood how English people set the position of arguments: I'm Latin! Getopt::Long::Sub sounds better? or you are saying that the Getopt::Long part is wrong? Something like Sub::Long::Arguments or what?

> Work on more use case first. And i don't mean mocks

The above code is a quick hack: I just covered what it came to my mind in the meanwhile, but it seems these example covering most use cases.

The assumption is that you finally get your arguments inside a hash (given its flaxibility this should cover most needs, imho). So you would call the futurible method from my unborn module in this way:

        # dest                   {defaults}            [template]     
+ original @_

        my %opts = longargs( {len => 1, wid => 2}, [qw( len=i wid=i )]
+, @_ );
[download]

Which use cases are you imagining?

Thanks for looking

L*