[ saw this in port-i386 where it's definitely in the wrong place.
  we don't have a tech-religion list though :-/  ... ]

> The problem is simple: you can't read /proc from your kernel core
> dump!

With a "good implementation"[TM] why not ?  Think of a procfs
that will compile both for kernel and userland, where the userland
version operates on a coredump.

> The /proc and /kern we ship with were written mostly for hack value
> from what I understand.

It goes a bit deeper than that.  Yes, there's the hack value of
"proving" that the 4.4BSD filesystem code "could do it" but I
certainly do remember at least jsp being very taken with the
Plan 9 extension of the unix "all the world's a file" abstraction
principle to its logical limit, which is what provided the motivation
for the hack value in the first place.

Seems to me to be mainly a religious issue.  Traditional unix-heads
who believe in the "all the world's a file" abstraction to have
priority over all other concerns will obviously take this religion.
Certainly the idea that /bin/ps should just be an awk script is
something that should be attractive to any minimalist, but the
point that makes it a religion is that it just moves the work
elsewhere.  It's a religious question (ie a judgement call)
to decide just where to put the work so as to minimise the
total amount of work.

Of course there is the counter-argument of "if you want plan9,
you know where to find it" :-) but that's not acceptable to me.
Plan 9 doesn't have the large user community and the licensing
terms that netbsd does.  Nor the cross platform support.
Nor the product maturity.

And if core@netbsd.org doesn't subscribe to the plan9 religion,
I'll live with it.  I can't put up, so I'll shut up, in other words.

--