Obligatory nitpick: C libraries should be careful to prefix all exposed identifiers, to minimize the risk of collision. But when you include picoc.h, which is careful to do this, you also get interpreter.h, which... is not.
The other factor is that the code as it stands is designed to be as readable as possible. I'm conscious that prefixing every identifier with "PicoC" will make the whole thing a bit less easy to read. I'm not sure if maximising readability is something that people really care about though. I'd be interested in hearing people's opinions on whether they'd prefer "struct ValueType" or "struct PicoCValueType" in a thousand places throughout the code.
I stopped using the file name at all in my include guards a few years ago, and use a GUID instead. For example:
#ifndef HEADER_6AFF21D71B5B43DEB079AA612E4118B4
#define HEADER_6AFF21D71B5B43DEB079AA612E4118B4
#endif//HEADER_6AFF21D71B5B43DEB079AA612E4118B4
Depends on your target platform. GCC, clang/LLVM, Visual C++, and many proprietary compilers all support it. What platform are you targeting that doesn't support it?
Because if you're writing any non-trivial useful code, it's highly likely that your code is not pure ISO C; you're using some library with support for various platforms, or a system call interface, or some other interface to a real system. Once you do that, universal portability no longer applies, so you might as well think about which specific target platforms you care about.