Answering a few things...

> x86-64 was first introduced in 2003 (announced in 1999 though apparently), so Hurd is over 2 decades late on this.

No, it's a decade early against the 2038 deadline, which was the real constraint.

Also, only now we see software not support 32b systems at all ; that notably pops up in Debian.

Porting just for the fun of porting can be nice, but there are also other priorities.

> I don't know the story behind that, but why would anyone spend effort on this rather than one of the many other faster moving OSes at this point?

The hurd does have a FAQ...

https://www.gnu.org/software/hurd/faq.html

> there is Redox

Redox has various design issues, which hinders quite a few flexibility possibilities. I have tried to discuss with them a couple of times at FOSDEM, but they don't seem to be interested in learning from existing experience in microkernel OS...

> it would be appropriate to call a Hurd-based Gentoo or Debian system "Linux/Hurd", because the userland is Linux.

It's what people could often call "Linux", yes, but basically it's "FOSS", and not actually really tied to Linux. The typical example is util-linux, which works great and is useful on non-linux systems.

> If it had been strictly GPL v2, it would have been helpful because

That's precisely where the Hurd approach flies: since it can use several processes with a standard API in between, it can use GPLv2 code in a process and other incompatible licences in other processes.

> it could have borrowed code from the Linux kernel

It does...

> (imagine a Hurd with a driver compatibility layer for Linux drivers).

That already does exist, that's called netdde. That's what is currently used for network drivers, running in a userland process.

But Linux is a fast-moving target for such a glue code. So the more maintainable approach is using the bsd code with rump.

> I don't see the advantage to the user of splitting the kernel services into a bunch of loosely coupled components.

Please read the FAQ.

> Now they all have to be managed, and you depend on all of them to be working.

But when one is not working, you can identify it, and possibly restart it. While when it's a monolithic kernel that has a problem, you have to restart it all.

On Linux, I do see my audio card driver get stuck from times to times, and I have no other option than restarting my whole box. No, I can't remove the module in that case, it's all completely stuck.

> nobody is interested in writing device drivers for it.

It would be a waste of time. I see various OS projects doing this. While it's fun to write drivers, you don't want to maintain it all. Thus the rump approach.

> According to the web pages,

Which web page?

> there's three drivers they took from the NetBSD rump kernel and, er, that's it.

What do you call a "driver"?

The ahcisata + piixide + usbhc drivers? That already covers a lot of disks. And that's just a start for keeping things simple first. Then it's a matter of enabling more, rump was exactly meant for that.

> An NVMe driver is about a thousand lines of code (assuming you don't bother to support the insane NVMEoF extensions). And nobody's done the work to write it!

Again, that would be a waste of time when rump can just provide it, the driver is there in rump, it just needs somebody to try enabling it and checking that it works.