Well, at 3h this morning I had it mostly working again. I think the order of mishaps was
1) me setting PATH in the launchctl environment 2) before undoing that (and rebooting), me calling `startx` or running X11.app from a terminal as root with the idea that the IPC error might go away because of that 3) me seeing the warnings about .Xauthority and somehow thinking "I don't have that file anyway" rather than checking and discovering it had been "stolen" by root during 2) So after fixing 3) and running `xauth -b` for good measure my X11 environment starts again. I haven't yet had the chance to check if remote connections work, but local connections via `DISPLAY=hostname:0` do work again (they didn't with my hands-on call to `xinit` without `-auth` file). Jeremy pointed out that we need privileged_startx, the launchctl plist I had moved aside for forgotten reasons. So I moved it back and loaded it before launching X11.app after the fixes above. Before all this I'd been tinkering with epiphany, the Gnome WebKit browser, so that was the 1st thing I tried to launch from my restored X11 session. Boom, BadAccess and abort. `zenity --calendar` and `gtk3-demo-application` also do the same thing. Curiously, they do NOT when I run them with `env DISPLAY=Portia.local:0.0 foo` . Tracing shows the culprit is a call to XCreatePixmap from `gdk_window_set_icon_list` (GTk 3.24.20). Evidently I unloaded that privileged_startx plist, moved it back to its -disabled folder and restarted X11. Now, these applications will start OK, but only for a few minutes in (or maybe just starting one triggers a who-knows-what that causes the BadAccess error on subsequent runs). Needless to say, this is new. Does this ring any bells, an X11 operation that raises a BadAccess when run over the local DISPLAY socket but not when it goes (IIUC!) via the TCP layer? Thanks, R.
