>So doing a function inside a .h file and using it inside multiple .c files will mean you have the same function multiple times and it will throw a linker error if the function is not static.

This is prevented by a header guard.

And, also: if you have the same function defined elsewhere, and your compiler complains about it: good. That is a bug.

Single-header projects like this are useful because they can be very easily integrated - just include the header, and build. No need to add another .c to the project, get its compile and link target inserted in the project. The single-.h approach makes sense for a project like this, where indeed the purpose is to put an embedded language/compiler, with as little fuss as possible, in any particular C-based project.

If the author caters to the desire to scratch the convention itch, and moves everything to .c - this just adds another layer of cyclomatic complexity to the project management. I'm a lot more inclined to try out such a radically useful project if its a single header - or can be expressed as a single header - than if I have to edit my project, add new .c targets, get the linking done properly, etc. Single .h with header guards - done properly (i.e. namespace) - can make such projects immediately more attractive than if it comes with a heavy load to integrate ..