You know, your PDF reader probably has a search function, and the book itself has an index, which has numerous references to NeXT and NeXTSTEP.

NeXT: 11, 14, 230, 296

NEXTSTEP: 11, 14, 54, 141

OpenStep: 14, 141

Page xxxi of The Unix-Haters Handbook mentions: "In fact, it was typeset using FrameMaker on a Macintosh, a Windows box, and a NeXTstation." (Affectionately called "PainMaker" by its victims.)

I wrote three long paragraphs about NeXTSTEP (however you choose to spell and capitalize it), comparing it to NeWS and Display PostScript, in the X-Windows chapter. I even gave Steve Jobs a NeWS demo and a "NeRD" button at EduCOM, the month NeXTSTEP was finally released in November of 1988 (until then it was considered vaporware, and derisively called "NeVRSTEP" -- the critics even made t-shirts):

>I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade show floor at the Educom conference, right after he finally released the NeXT Machine, in November of 1988.

>Sun was letting me demo NeWS and the stuff we were developing at the UMD Human Computer Interaction Lab on a workstation at their booth, and NeXT's booth was right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him over for a demo. He jumped up and down and yelled "That sucks! That sucks! Wow, that's neat. That sucks!"

>I figure a 3:1 sucks:neat ratio was pretty good for him comparing something different than his newborn baby NeXT Step, which critics had taken to calling NeVR Step, since it had been vaporware for so long until then.

>When I tried to explain to him how flexible NeWS was, he told me "I don't need flexibility -- I got my window system right the first time!"

And one of the editors, Simson Garfinkel <simsong@nextworld.com>, wrote a popular book about NeXTSTEP and was a senior editor at NeXTWORLD magazine.

p. 11:

Date: Wed, 20 Nov 91 09:37:23 PST
From: simsong@nextworld.com
To: UNIX-HATERS
Subject: Unix names

Perhaps keeping track of the different names for various versions
of Unix is not a problem for most people, but today the copy
editor here Standardizing Unconformity 11 at NeXTWORLD asked me
what the difference was between AIX and A/UX.

“AIX is Unix from IBM. A/UX is Unix from Apple.”

“What’s the difference?” he asked.

“I’m not sure. They’re both AT&T System V with gratuitous
changes. Then there’s HP-UX which is HP’s version of System V
with gratuitous changes. DEC calls its system ULTRIX. DGUX is
Data General’s. And don’t forget Xenix—that’s from SCO.”

NeXT, meanwhile, calls their version of Unix (which is really Mach
with brain-dead Unix wrapped around it) NEXTSTEP. But it’s
impossible to get a definition of NEXTSTEP: is it the window
system? Objective-C? The environment? Mach? What?

p. 13 (although the index says 14: blame PainMaker, which is riddled with features!):

Sun Microsystems recently announced that it was joining with NeXT to
promulgate OpenStep, a new standard for object-oriented user interfaces.
To achieve this openness, Sun would will wrap C++ and DOE around
Objective-C and NEXTSTEP. Can’t decide which standard you want to
follow? No problem: now you can follow them all.

p. 53 (although the index says 54, thanks PainMaker):

Hmm… Excuse us for one second:

% ls /lib
cpp* gcrt0.o libsys_s.a
cpp-precomp* i386/ m68k/
crt0.o libsys_p.a posixcrt0.o
next% strings /lib/cpp-precomp | grep /
/*%s*/
//%s
/usr/local/include
/NextDeveloper/Headers
/NextDeveloper/Headers/ansi
/NextDeveloper/Headers/bsd
/LocalDeveloper/Headers
/LocalDeveloper/Headers/ansi
/LocalDeveloper/Headers/bsd
/NextDeveloper/2.0CompatibleHeaders
%s/%s
/lib/%s/specs
next%

Silly us. NEXTSTEP’s /lib/cpp calls /lib/cpp-precomp. You won’t find
that documented on the man page either:

next% man cpp-precomp
No manual entry for cpp-precomp.

p. 140 (FrameMaker's index says 141):

X Graphics: Square Peg in a Round Hole

"Programming X Windows is like trying to find the square root of pi
using roman numerals." —Unknown

The PostScript imaging model, used by NeWS and Display PostScript,
solves all these horrible problems in a high-level, standard, device independent manner. NeWS has integrated extensions for input, lightweight processes, networking, and windows. It can draw and respond to input in the
same arbitrary coordinate system and define window shapes with PostScript paths. The Display PostScript extension for X is intended for output
only and doesn’t address any window system issues, which must be dealt
with through X. NEXTSTEP is a toolkit written in Objective-C, on top of
NeXT’s own window server. NEXTSTEP uses Display PostScript for
imaging, but not for input. It has an excellent imaging model and well designed toolkit, but the Display PostScript server is not designed to be
programmed with interactive code: instead all events are sent to the client
for processing, and the toolkit runs in the client, so it does not have the low
bandwidth, context-switching, and code-sharing advantages of NeWS.
Nevertheless, it is still superior to X, which lacks the device-independent
imaging model.

On the other hand, X’s spelling has remained constant over the years, while
NeXT has at various times spelled their flagship product “NextStep,”
“NeXTstep,” “NeXTStep,” “NeXTSTEP,” “NEXTSTEP,” and finally
“OpenStep.” A standardized, consistent spelling is certainly easier on the
marketing ’droids.

Unfortunately, NeWS and NEXTSTEP were political failures because they
suffer from the same two problems: oBNoXiOuS capitalization, and
Amiga Persecution Attitude[TM].

p. 230 (hey FrameMaker got one right!!!):

Footnote 2:
Indeed, there are so many problems with partitioning in Unix that at least one vendor (NeXT, Inc.) recommends that disks be equipped with only a single partition.
This is probably because NeXT’s Mach kernel can swap to the Unix file system,
rather than requiring a special preallocated space on the system’s hard disk.

p. 295 (FrameMaker guessed 296, two out of six ain't bad):

Date: Wed, 18 Sep 1991 02:16:03 GMT
From: meuer@roch.geom.umn.edu (Mark V. Meuer)
Organization: Minnesota Supercomputer Institute
Subject: Re: File find delay within Emacs on a NeXT
To: help-gnu-emacs@prep.ai.mit.edu

In article <1991Sep16.231808.9812@s1.msi.umn.edu>
meuer@roch.geom.umn.edu (Mark V. Meuer) writes:

I have a NeXT with version 2.1 of the system. We have Emacs
18.55 running. (Please don’t tell me to upgrade to version
18.57 unless you can also supply a pointer to diffs or at least s-
and m- files for the NeXT.) There are several machines in our
network and we are using yellow pages. The problem is that
whenever I try to find a file (either through “C-x C-f”, “emacs
file” or through a client talking to the server) Emacs freezes
completely for between 15 and 30 seconds. The file then loads
and everything works fine. In about 1 in 10 times the file loads
immediately with no delay at all.

Several people sent me suggestions (thank you!), but the obnoxious
delay was finally explained and corrected by Scott Bertilson, one of
the really smart people who works here at the Center.

For people who have had this problem, one quick hack to correct it is
to make /usr/lib/emacs/lock be a symbolic link to /tmp. The full
explanation follows.

I was able to track down that there was a file called !!!SuperLock!!!
in /usr/lib/emacs/lock, and when that file existed the delay would
occur. When that file wasn’t there, neither was the delay (usually).

We found the segment of code that was causing the problem. When
Emacs tries to open a file to edit, it tries to do an exclusive create on
the superlock file. If the exclusive create fails, it tries 19 more times
with a one second delay between each try. After 20 tries it just
ignores the lock file being there and opens the file the user wanted. If
it succeeds in creating the lock file, it opens the user’s file and then
immediately removes the lock file.

The problem we had was that /usr/lib/emacs/lock was mounted over
NFS, and apparently NFS doesn’t handle exclusive create as well as
one would hope. The command would create the file, but return an
error saying it didn’t. Since Emacs thinks it wasn't able to create the
lock file, it never removes it. But since it did create the file, all future
attempts to open files encounter this lock file and force Emacs to go
through a 20-second loop before proceeding. That was what was
causing the delay.

The hack we used to cure this problem was to make
/usr/lib/emacs/lock be a symbolic link to /tmp, so that it would
always point to a local directory and avoid the NFS exclusive create
bug. I know this is far from perfect, but so far it is working correctly.

Thanks to everyone who responded to my plea for help. It’s nice to
know that there are so many friendly people on the net.