> 1. Addition of TSEMACQUIRE system call.  Does it have other applications?

I missed this; is there any documentation that clarifies this issue?
I think it's important to provide a rationale for structural changes
and Bell Labs are a little too glib with their patch releases, in my
opinion.

> 2. Use of Go's libbio, rather than Plan 9's. Alternatively libbio on Plan 9
> can be changed. It's not clear to me why this would be a bad thing.

The functions are very readily added to libbio without side effects.
The macros, on the other hand, are an embarrassment and trigger dozens
of warnings (to the best of my ability to check).  There really ought
to be no warnings in compiling the Go tool chain for Plan 9; the
bison-related stuff deserves some attention, too.

> 3. Modifications to 8g to get around an 8c bug (for the curious, see the
> test case from Anthony that reproduces it, below). Go team accepted the
> patch to get around this, even though it is a bug in Plan 9's 8c.

The patch was a bit of a scream.  I'm the first to admit that 8c needs
a touch of TLC and that an abort() in the middle of a compiler,
without the slightest attempt to deal with the problem is at least as
embarrassing as the expansion of BGETLE, but the original code that
tripped the compiler was also extremely shoddy.  And the Go
developers' resistance to rewrite a few badly thought out lines of
code did come back to bite them in the ass.

> 4. modification to get around having to use runtime·memmove in
> runtime·sighandler

The right answer here is to have a plan9·memmove until Bell Labs
figure a way to classify some opcodes as other than floating point and
allow them where the architecture permits it.  It's a big problem, but
it needs to be addressed, the world of CPU extensions is still young
and, sadly, not still-born.

The Go developers will eventually need to adjust to this reality too.
Arm64 is a hint of things to come.

++L