If you mark a function as static, it means that has internal linkage and is only visible inside the translation unit was defined and no symbol is exported for linking. This is not the default: if you just define a function with some name, that symbol is in general visible to all other translation units that gets linked together by the linker (though with no type information attached, just the name of the symbol. Making sure the type information is correct is the purpose of header files).
That means you can have any number of functions marked static in different translation units with the same name, and it's fine, they don't see each other. If you're doing an amalgamated build like this, that no longer works: all symbols have to have globally unique names.
In addition, of course, you don't get the "separation" that "static" provides. You can't call a static function across a translation unit boundary, but since this just one big translation unit, anything goes: all functions can call all other functions, even if they shouldn't.
It does. Any technique that relies on features specific to translation units, such as taking advantage of internal linkage to reuse symbols to hold data specific to translation units, cannot be used anymore.
Also, even though global builds are faster, you forego the ability to do incremental builds which makes working over a bug a more time-consuming task.
These are actually called "unity builds" or "jumbo builds", and some build systems such as CMake offer support for this.
https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.htm...
This style is called "amalgamation" and SQLite is distributed (but not developed) in this way.