Greetings!

Unfortunately I can not answer any of that right now. I have never ever
thought about routing automatisation/easiness. NNCP was never intended
to do that kind of things. Being friend-to-friend in my opinion means
that no "automagic" routes/neighbours distribution occurs -- human has
to explicitly make all required decisions. I mean I am not against that
kind of things, but at first glance do not sympathise that features,
ignorant to them.

>The ultimate idea is that NNCP users should be able to send email to
>username@NODEID.nncp without having to have previous knowledge of it or
>direct knowledge of how to route a packet there.

In my opinion that is exactly what (completely) distributed networks do,
peer-to-peer ones with automatic peer discovery. And in my views that
some kind of opposes friend-to-friend network, where you have to
explicitly set authentication/trust/knowledge about each peer. NNCP was
not designed with such things in mind. I do not want to say that it is
impossible with current design decisions, but personally I would not try
to implement distributed network with peer's (routing) autodiscovery on
top of existing implementation, but would redesign it from scratch
probably.

>Question: if a destination is not given in nncp.hjson, but its -via step
>is, can we send a packet to it simply by giving its full node ID as the
>destination?  That is, if the node ID is the public key, that should
>theoretically work, right?

No, because node's ID is a hash of node's signing public key. Even if it
was (actually they have got the same length) the signing public key
itself, each node also has "exchpub" key (curve25519 public key that is
used in Diffie-Hellman key agreement to derive shared encryption key for
packet encryption). Using of hash(signpub) instead of signpub is not
necessary step, just used to more uniformly distribute ID's value at
256-bit value space. If node's ID will be concatenated 512-bit
"exchpub"+"signpub", then it could be used to immediately create
outgoing packet to that node indeed.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A