1. randomly with any extra data that can be false so that it confuses others
All messages are encrypted so it doesn't really matter what you put inside (still, the specs recommend using zeros). The overall size of the message is more important as standardised messages have a fixed size, so a third-party might try to guess what you are talking about with some other node.
2. with onion routing to have private updates, or (1) because just waiting for a official update can be "no new data for a significant portion of a connection's lifetime"
I have no idea where you got the "private updates" from. Your quote suggests that you can create synthetic traffic in combination with BOLT04. In other words, for example, you can send ping messages while routing a payment to pretend that the payment was split or forwarded to a different node.
3. to do other things like changing keys
Encryption keys are changed every 500 uses. Ping/pong messages count as one use. They are not used to exchange new keys.
yep you can put in lots of stuff into the extension part.. but you keep dismissing this. maybe you dont understand, or maybe your purposefully ignoring what happens with TLV in the extension
Let me explain my point again. Here's what you said before:
but there are hundreds of messages.. heck even the simple ping/pong messages can include updates to the fee's cltv's and such.
Yes, technically you can fit this information in there. However, an optional TLV payload was not a part of the initial specs and the Lightning Network works well without depending on it. Here's how I replied to you:
Even the ping/pong messages? Are you sure that we are looking at the same specifications? You might as well put a picture of your cat inside of your "ping" message, but the recipient won't know how to handle it correctly as it's non-standard.
None of the existing wallets or implementations expects information about fees, ctlv timelock or liquidity in the TLV payload. They would ignore it. Sure, you could modify your client to behave this way, but you would still have to comply with the specifications to be able to talk with other nodes without any problems.
and if C is private. there wont be a BC or CD or CW on the DNS network bootstrap map..
instead of seeing a tree that links
ABCDE
ABCWXYZ
ZYXWCBA
ZYXWCDE
you would instead see
AB ZYXW
If we assume that all of the C's channels are private then you are correct. Although, "DNS network bootstrap map" is not really a suitable name for DNS bootstrapping used by new nodes and a local map of the network.