I can NOW.... but only after days and hours of work because the install always failed on grub install and with no specific reason why beyond "Oops. Something went wrong with grub-install..." . So I had to fumble around to get Ubuntu to boot by any means, mostly thanks to Slackware and install media chroot.

It works now, but if I had to start from scratch and install Ubuntu again I have learned absolutely nothing on how to satisfy the installer and would once again just have to chip away trying stuff until it once gain finally would boot. That's a problem for me. I prefer to know than guess.

I did recently buy an M.2 drive caddy that allows treating NVME drives of any size as if they were freely exchangeable floppies. Maybe turning off all other drives and submitting to letting Ubuntu take over a drive in the caddy would satisfy it, but that would be a serious PITA.

From what I see from the first pastebin, after another look, assuming this is done from ubuntu, the boot partition is mounted:
The efi partition is not mounted:

Good catch, colorpurple21859, but largely irrelevant, certainly to the initial installer failure. I employ redundancy for options when catastrophe strikes (often self-inflicted... I tinker to learn) but I rely on one boot system from one drive 90+% of the time, /dev/nvme1n1p1, as BIOS/UEFI and Slackware sees drives. FWIW its UUID is E9A2-0EB5.

Grub systems prefer/require? UUID so dev can change willy-nilly. Oddly, partition managers, have consistency in device order and even the KDE Partition Manager in Ubuntu Live Installer sees dev order consistently the same as all the rest. Despite the inconsistency in many systemd based distros, which I suspect may have something to do with the whole switchroot thing, protected against with UUID, NUBUFI is actually /dev/nvme0n1p2 not /dev/nvme1n1p2.

It may be worthy of note that NUBUFI actually begins at the very start of nvme0n1 but is only labelled nvme0n1p2 because originally it was a storage drive and the first partiton was shrunk to make room for other partitons which get subsequent numbering.

I have no idea why KDE Partition manager in Ubuntu saw esp partitions as "fat32" since "vfat" has always worked for me but for a time in trying to conform to Ubuntu I designated ESP as Fat32 in fstab. Worked sometimes, sometimes not. I changed it to vfat and now it consistently works and rather nicely, actually.

However after all that, unfortunately I still haven't a clue as to why the installer had such failures in a partition scheme (actually more than one) that obviously works just fine when handled by a human on-the-job.

It could simply be AI spite knowing I employ automation very sparingly I prefer to own my PCs not "lease" them and I hate stuff going on out of sight. When failure of any kind occurs, I want to know it was the very last thing I did. I can fix that. It's very much harder to fix what isn't seen that requires leaping though many hoops just to discover what failed before fixing it.

I know... I'm an oddball but that may partly be due to my first GUI being neither MS or Apple. I started on PCDOS with Midnight Commander and PCShell and graduated to OS/2 v2.1 or maybe that was just the effect and the cause was me all along.

I get what you're saying, I also like to know what is going on underneath the hood as the saying goes.

Then you might just enjoy taking this vehicle for a spin - https://docs.slackware.com/slackware:liveslak