In C++, when I ask someone what a translation unit is, the popular response is that it is usually a source file. static and extern modify how global functions and variables are accessed by other translation units. Can translation units be something else, too? For example, an assembly file (not .cpp with inline ASM)? Or a .dll? I've seen experienced software engineers make such programs.
My experience with C++ is largely with microcontrollers, so I am used to making a main.cpp, some .h files, and including a few libraries from PIO or GitHub, but not using ASM.
Another source of confusion, some say that all of the includes are also part of the same translation unit. If that were so, then static and extern would not behave the way I believe they do now. I would really like to clear some of the confusion associated with translation units.
Is a Translation Unit always a file?
No, it does not have to be. For example, the standard library headers (and other source files) could in theory not be files in the filesystem. They could be something internal to the compiler, contained within the compiler executable, or found in a database, or whatever. A translation unit is usually a source file, but you cannot assume that.
Another source of confusion, some say that all of the includes are also part of the same translation unit
Sure they are. When a source file is compiled, the preprocessor has already run and basically copy+paste'd all the includes into the source file that the compiler sees. So, from the compiler's perspective, the includes are part of the compilation unit, since all their contents were pasted into the file the compiler was given. The compiler never sees #include directives - those are all handled by the preprocessor before the compiler ever sees the file/translation unit.
See also:
https://en.cppreference.com/w/cpp/language/definition