TLDR; What is the intended way forward for applications that depend on max-au/argparse - in OTP26 there is a new argparse module in stdlib that provides similar functionality with a different API?
I am slightly late to the party, but I finally got around to make sure that our system (currently running on OTP23-25) can also build and run on OTP26. And apart from a couple of 3rd party libraries warning about matching 0.0 it all was pretty smooth until:
===> Error generating release:
Duplicated modules:
argparse specified in stdlib and argparse
Turns out one of our used dependencies clashes with new functionality in OTP26. Or, wait, not so much clashes, it seems to be the same thing (from the open PR in https://github.com/max-au/argparse):
Warning This project is no longer maintained, because argparse is now a part of Erlang/OTP: https://www.erlang.org/doc/man/argparse.html (starting with OTP 26). If you need code in cli.erl, feel free to copy and paste it directly in your project.
Oh, great, then I just need a way to tell rebar3 that starting from OTP26 we don’t need the dependency - easy, right?! Ok, a few hours and lots of support from @eproxus later there is a rebar.config.script, a rebar.lock.script and an <myapp>.app.src.script - and the right things are building and running.
All good? Nope, tests fail, in fact lots of tests fail…:
escript: exception error: undefined function argparse:format_error/3
Huh? I was told it was the same thing? No, not so much. Turns out the API is changed subtly (and not so subtly) in the OTP26 version. I.e. there needs to be OTP-version dependent code in there if you want to proceed down this route. Is this how you are supposed to do this, or what solution did the OTP-team think of when they decided to add a module with the same name but different behavior?
I guess the way forward right now is to clone argparse rename the argparse module, update my code and be happy. And then after OTP29 I can revisit the topic, rewrite the code and drop the dependency 
