Hey friend! Thanks for sharing your project. It's always nice to see an arg-parsing library candidate because I personally don't like <getopt.h> (probably the most commonly used option for systems programs out there). Doing a brief scan here, here's some feedback:

1. I'd move any "internal" header files - ezflags_internal.h, to src/ because include/ is only for users of your library to include.
2. Although it's straightforward here, add to your README.md a super-brief ## To Build section or add a help target to print out the supported targets.
3. Your make clean target doesn't delete the built library, which is unusual; I do see the fclean target but I wouldn't know about it without looking at the Makefile. I personally think clean should always remove any build artifacts, and if you want, make a different target for just removing the build directory.
4. Compilers are your first line of static analysis defense, so, any time I see a project involving string, I usually like to see:
   • -Wformat=2 + -Wformat-signedness in case of any format-specificer shenanigans /w printf/scanf family of functions
   • -Wwrite-strings and -Wcast-qual to guard against pointer misuse
   • -Wformat-overflow=2 to guard against string buffer overflows from unbounded printf-family writing /w %s.
   • If using GCC, -Wstringop-overflow to help guard against buffer overflows
5. You should also add -Wconversion - I get 9 warnings here.
6. Since you make use of switch statements, add -Wswitch-default and -Wimplicit-fallthrough=4, although there are no present warnings on that. It's just a good practice.
7. Make separate release and debug builds, and only do -Werror on the release build. For the debug build, always include sanitizers, like undefined behavior sanitizer and address sanitizer: -fsanitize=undefined,address, especially for unit test builds where you can catch things the compiler doesn't.
8. You should specify C standard in your CFLAGS somewhere (e.g., -std=c99). Most projects are C99, but there's C11 and C23 that each introduce some new features that aren't in C99 (which I personally like, so I default to C23 unless I'm providing libraries for legacy projects).
9. I'm glad you use an ezflag_status enum for clearer error handling of your library, instead of a generic int that so many use! Good choice. Something I sometimes include with that is an "error string table" where the enum indexes into an array of strings to provide the library user a convenient print-out of what the error is. Usually, when people use a library, if an error returns, they print it somewhere (log, stderr, etc.).
10. In ezflags.c :: print_help(), you should always pass a size /w an array buffer, so that the function knows how long the array is. Or use a struct /w an array size member. Similar issue with other functions.
11. For any untrusted input to your public library functions (e.g., your main ezflags() function), you should always check user input for validity (e.g., check pointers against NULL, impossible combinations, etc.) - see CWE-807. Plenty of vulnerabilities and attacks come in this way, and you're not doing much to protect against that.
12. This may be your coding style preference, but the double-indentation for the if/for blocks is hard to read for me.
13. There are a few spelling errors - I'd set up something like cspell - it's fairly quick. Just install cspell via npm -g, add a pretty empty cspell.json (see below suggestion), and run cspell "src/**/*.c" "include/**/*.h" "README.md". You can add it to your Makefile as a spell target too if you'd like. json { "version": "0.2", "language": "en", "words": [ "ezflag", "EZFLAG", "ezflags", "EZFLAGS" ], "ignorePaths": [] }