POSIX does not specify a complete operating system, so any POSIX-compliant OS will have commands that aren't in POSIX (like init, mkfs, passwd, …). But different OSes have different extensions, and GNU tools (found on non-embedded Linux systems) have a lot.
BusyBox is a set of command-line tools that is intended for embedded Linux systems. It contains most of the utilities and options mandated by POSIX (it's not complete, but it comes close). You can make a running Linux system with a bootloader, a Linux kernel, BusyBox, and Dropbear if you want to log in over SSH. Add Gcc if you want to do development on the minimal system.
If you prefer to start from a full but small distribution, look at MINIX 3. This is a small unix system intended for embedded systems and for teaching.
If you want a more easily extensible system, look at OpenBSD. OpenBSD is focused on security and is conservative on features, but the core system does include major components such as Perl and Apache.
There is no standard way to retrieve the list of configuration variables that are supported on a system. If you program for a given POSIX version, the list in that version of the POSIX specification is your reference list. On Linux, getconf -a lists all available variable.
fpathconf isn't specific to PATH. It's about variables that are related to files, which are the ones that may vary from file to file.
Regarding ARG_MAX on Linux, the rationale for depending on the stack size is that the arguments end up on the stack, so there had better be enough room for them plus everything else that must fit. Most other implementations (including older versions of Linux) have a fixed size.
Most limits go together with resource availability, with different resources depending on the limit. For example, a process may be unable to open a file even if it has fewer than OPEN_MAX files open, if the system is out of memory that can be used for the file-related data.
Linux is POSIX-compliant on this point by default, so I don't know where you're getting at.
If you use ulimit -s to restrict the stack size to less than ARG_MAX, you're making the system no longer compliant. A POSIX system can typically be made non-compliant in any number of ways, including PATH=/nowhere (making all standard utilities unavailable) or rm -rf /.
The value of ARG_MAX in limits.h provides a minimum that applications can rely on. A POSIX-compliant system is allowed to let execve succeed even if the arguments exceed that size. The guarantee related to ARG_MAX is that if the arguments fit in that size then execve will not fail due E2BIG.
Best Answer
No. The Open Group has an actual POSIX certification process, so if an operating system hasn't been through that, it cannot be referred to as POSIX-compliant.