As I understand it, part of the Unix identity is that it has a microkernel delegating work to highly modular file processes. So why is Linux still considered "Unix-Like" if it strays from this approach with a monolithic kernel?
I believe the answer lies in how you define "Unix-like". As per the wikipedia entry for "Unix-like", there doesn't seem to be a standard definition.1
A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the Single UNIX Specification.
There is no standard for defining the term, and some difference of opinion is possible as to the degree to which a given operating system is "Unix-like".
The term can include free and open-source operating systems inspired by Bell Labs' Unix or designed to emulate its features, commercial and proprietary work-alikes, and even versions based on the licensed UNIX source code (which may be sufficiently "Unix-like" to pass certification and bear the "UNIX" trademark).
Probably the most obvious reason is that UNIX and MINIX are antecedent of Linux, having inspired its creation.2
Torvalds began the development of the Linux kernel on MINIX and applications written for MINIX were also used on Linux. Later, Linux matured and further Linux kernel development took place on Linux systems.
Linus Torvalds had wanted to call his invention Freax, a portmanteau of "free", "freak", and "x" (as an allusion to Unix).
Whether a system is monolithic or microkernel does not seem to be considered when calling an operating system "Unix-like". At least, not nearly as often as whether the system is POSIX-compliant or mostly POSIX-compliant.
The "UNIX way" really refers to experience of the user. A small set of utilities can be combined to build an effective operating system command line. Related to this, operating systems utilities are in no way "special" or have power beyond programs which you can write yourself.
This is a difficult point to make these days, since UNIX was so successful in this aspect that it has become the way operating systems are expected to present their command line interfaces. The point is best illustrated by a counter-example: here's how to do
cp a.txt b.txt on a IBM mainframe:
//COPY JOB ,CLASS=E,MSGCLASS=X,NOTIFY=&SYSUID //cp EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT1 DD DSNAME=a.txt,DISP=SHR //SYSUT2 DD DSNAME=b.txt,DISP=(NEW,CATLG),UNIT=SYSDA
This won't even copy every type of file.
UNIX made a number of assumptions which simplify usability at the cost of performance. File channels 1 (stdin), 2 (stdout) and 3 (stderr) go to and from the terminal, removing a lot of the boilerplate from the JCL above. The filesystem supports one type of data -- bytes -- and one access mode -- sequential (although the pointer where the sequential data can be read or written can be moved to implement a sort of "random access"). This means that system utilities only need deal with one type of file and one type of data to cover all files and datatypes. The filesystem does not require pre-allocation. Adding files to the directory (aka "disk catalog" on IBM mainframes) happens automatically if the filename is known to the operating system.
These assumptions were so successful that these days we don't even give them a second thought. Whereas at the time they would have appeared profligate -- imagine the sheer overhead of a filesystem which wasn't told in advance the maximum size of a file.
But UNIX didn't stop there. It promoted a "toolbox" approach to system utilities. The mainframe's IEBGENER can print files, rearrange fields within records, drop records, create blank records. In contrast, in UNIX cp copies files, cat lists file contents, cut handles fields. There's a neat syntax for stringing the stdout of a command to the stdin of the next file, all on one terminal line. Using this "pipe" syntax and those small commands we can do everything which IEBGENER can do. And things which the authors of IEBGENER never dreamed of.
Kernighan and Plauger wrote an influential book in 1976 about this approach -- Software tools -- and that's really the first exposition of the "UNIX way". Kernighan and Pike restated this approach in their 1984 book The UNIX programming environment.
From my understanding "monolithic" is a misdiscription of linux. Monolithic means large and unchanging. The very fact that modules can be inserted into kernel space breaks the monolithic definition. I think the appelation of monolithic began in some talk by Greg Kroah-Hartman, where he sort of indicated that the word he used was not quite right, but people accepted that linux was monolithic. I think that often the terms micro-kernel and monolithic are considered exact opposites, when in fact they are not. linux is a non-monolithic kernel, but isn't a micro-kernal.
My understanding has always been that UNIX is both a trademark, and a technical specification.
In the Golden Era that was never the case, but I'm a youngster and, SCO v IBM moulded that.
UNIX®-is defined and endorsed by the amusingly named OpenGroup. https://www.opengroup.org/unix%C2%AE-systems
POSIX is a helpful, but slightly underwhelming specification over the years, wherein even since the bitter days of old, Microsoft Windows 2K achieved the necessary criteria. More recent iterations have brought harmony to the four nations, and Windows Subsystem for Linux v.2 is a compelling option to many enterprises with a heterogeneous server estate.
As far as I can tell, Linux has always dogmatically approached the consensus of "what is useful to the user", be they sys admin, developer, or end user, rather than "what does the special book say".