This warning logic is displayed as I described in the diff description, but I'm worried about one case that we might want to handle, but I'm not sure how:

When the detected IP somehow fails and network.json has wrong value (e.g. somebody left an old value there) - the warning won't be displayed, but the connection will be failing with no meaningful message.

I thought about it more and I think we can leave it.
There's no good solution without displaying excessive warnings either way and this situation will be rather rare. Also, if we remove the network.json entirely, this warning flow can be simplified and its content could then suggest setting COMM_NAT_DEV_HOSTNAME instead (introduced in D6293).
Another possibility is to display some messages directly in app.config.js - they'll be visible only in the Metro console, at the very beginning.

I like COMM_NAT_DEV_HOSTNAME better than network.json because it's less "sneaky" – you'll probably have a change in your Git working copy (in package.json) if you're overriding it, so you're less likely to have a "silent failure" you can't figure out how to resolve.

Another possibility is to display some messages directly in app.config.js - they'll be visible only in the Metro console, at the very beginning.

I like this idea! I think it would be good to log for two cases:

• Where autodetect fails, we can then request the user sets COMM_NAT_DEV_HOSTNAME
• If COMM_NAT_DEV_HOSTNAME is set and does not match autodetect, we can display a message eg. "IP address autodetect has been overriden by COMM_NAT_DEV_HOSTNAME"

Agreed, these cases make sense to me!

I created https://linear.app/comm/issue/ENG-2743/rework-networkjson-warning to track this further