[skissane]

> I think my point is clear enough though: if we consider the design and architecture, rather than compatibility

Is there such a thing as a Unix “design and architecture” though? The architecture of Linux and XNU are quite different. Hurd even more so (as you say, if you count that). Later AIX versions moved to a much more standard architecture, but the original AIX (for the IBM RT-PC) ran on top of a microkernel (VRM) which was allegedly written in a PL/I dialect not C (the microkernel was shared between AIX and PICK OS, and you could run AIX and PICK simultaneously on the same machine, with the microkernel ensuring they didn’t step on each other’s toes). Historically, Unix was mostly about the APIs, not changeable details of how they are implemented internally. AT&T’s early 1980s port of Unix to IBM S/370 mainframes was essentially a compatibility layer running on top of IBM’s TSS/370 time-sharing operating system. That’s a very different architecture from most other Unixes, except maybe z/OS (although TSS and MVS were distinct IBM mainframe OS lines, the former now long discontinued), and Cray UNICOS’ ability to run as a guest under COS. Yet it is both a genetic Unix (based on the original code) and from AT&T themselves, so what sense does it make to say it isn’t “really” Unix? But if it counts, why not z/OS?

[lproven]

> Is there such a thing as a Unix “design and architecture” though?

I think so, absolutely yes.

Internals of kernel are largely irrelevant, I would submit. That's not visible to the user. Minix 3, Darwin atop XNU, HURD, doesn't matter: boot it in single-user mode and they all look much alike. Cryptic little terse commands, all in lower-case, with single-letter switches after `-` and these days often full-word ones after `--`. Lots of cryptic little plain-text config files, both in a global directory (usually in `/etc`) and in the user's home directory (usually under `/home`). No drive letters or indicators, one global filesystem, directories separated by `/`.

Then look at the things that are only pretending to be a Unix, from NT to OpenVMS to z/OS, and there's a totally different shell or set of shells, there are drive indentifiers and maybe directories, maybe not, with who-knows-what as the delimiter. NT has "real" internal identifiers mapped to Windows-like ones and to Unix like ones, these days via at least 3 entirely separate subsystems: the original POSIX subsystem, much enhanced; and WSL 1, with code from the Windows Android runtime emulating a Linux kernel; and WSL 2, using Hyper-V to run a real kernel in a special porous VM. (Talk about baroque!)

I think it's very clear which of these are UNIX-like designs, with a Unix-like filesystem and a Unix-like shell and so on, and other ones, where but it's a (maybe option) extra, it's not the real underlying OS and you can quite possibly ignore it and never see it, or even remove it, and you can't use the Unix-like personality to run and administer your machine.

Yes, I think it's a real and important distinction.

QNX, say, is Unix-like. VMS, say, is not. Even if one has better compatibility with the notional "real thing" than the other.

[skissane]

> Lots of cryptic little plain-text config files, both in a global directory (usually in `/etc`)

Okay, but AIX quite notably deviates from that, in that it stores a lot of its system configuration in binary format, in a database, the Object Data Manager (ODM). In some ways, AIX's philosophy about storing system configuration is closer to the Windows Registry than to traditional Unix systems. Does that therefore mean that AIX deviates from "Unix design and architecture", and hence isn't a "real Unix"?

> Then look at the things that are only pretending to be a Unix, from NT to OpenVMS to z/OS, and there's a totally different shell or set of shells, there are drive indentifiers and maybe directories, maybe not, with who-knows-what as the delimiter.

So one of your arguments here seems to be, that if a system supports a non-POSIX path name syntax, it cannot be a "real Unix"? Or if its native path name syntax isn't POSIX path name syntax, it can't be a "real Unix"?

But, isn't it true that z/OS natively supports POSIX path name syntax? I mean, when you give z/OS a Unix path, if it is a path to a Unix file it never translates it to an MVS dataset name, because Unix files aren't datasets and don't directly belong to the MVS VTOC filesystem. Now, it is true that the Unix file is contained in a Unix filesystem (HFS or zFS), and that Unix filesystem is contained in a VSAM LDS dataset in the VTOC filesystem. But, if you compare that to z/Linux – a file is contained in a Unix filesystem (ext4 or whatever), and the Linux kernel supports storing that filesystem as a non-VSAM dataset in the VTOC filesystem – so z/OS and z/Linux actually behave pretty similarly here, at least when you use the Linux kernel's IBM VTOC support, the only actual difference is whether the filesystem dataset is VSAM LDS (DSORG=VS) or non-VSAM (DSORG=DA). Also, z/Linux can actually read (non-VSAM/PDSE) datasets in VTOC filesystems (using zdsfs from s390-tools), and for both z/OS and z/Linux, access to MVS datasets in VTOC filesystems is done using a hybrid between Unix and MVS naming syntax (although the details are somewhat different in each case). z/OS supports write too, but I don't see why that's a fundamental issue, given that other components of s390-tools (such as fdasd) have some degree of write support. z/OS and z/Linux are more alike than you seem to think.

[lproven]

> Okay, but AIX quite notably deviates from that [...]

No, I don't think so. It's a complex mature commercial one that goes its own way, but it's still a Unix, wit the core original Unix abstractions and models. It doesn't have a different native API or UI instead or underneath.

> But, isn't it true that z/OS natively supports POSIX path name syntax?

TBH I have never worked with it and don't know enough to say, but no, I don't think so. It has multiple sets of APIs and its core model is not the Unix model; it predates Unix altogether.

What I am saying seems simple and clear to me, but you seem to wish to obfuscate it and then claim that the obfuscated version falsifies the basic premise.

POSIX and its 21st century successor the UNIX™ certification process are about compatibility and only compatibility. If it's compatible with the UNIX tests then its makers can say it's a UNIX.

I am not debating that. You are.

I am saying:

If the OS started off Unix-like with the Unix model, a Unix style single filesystem tree, a Unix-like shell, etc. and never had anything else instead or alongside or underneath, that's a Unix-like OS.

If it added this later, alongside some other designs, APIs, shells, filesystem layouts etc., then it may end up being 100% compatibile and therefore it may be a UNIX™ but that does not make it a Unix-like OS in design.

Is that so hard?