Ideally this setting should also be available to other nodes to query that may also expose their own TCP/UDP ports for example the Email MTA node

Is this intended to be a global indicator of "don't bother to offer this node if inbound connection isn't allowed" - or a specific flag per node (one for udp, one for tcp, one for email - etc ) ?

In the first case as it is then down to individual nodes to implement the flag needs to make clear it is more of an indication that can be followed rather than a hard rule.
In the second - is there a proposed naming convention ? disallowInboundXxx ? or something ?

I think a single global flag indicating that the environment doesn't support inbound connections are not available is the right approach.

I agree (with @hardillb ) - though is it true all the time ? can I have internal (localhost) connections from another process ? Or is that sufficiently edge-case that it doesn't matter ? (I suppose worst case the setting could be turned off :-) even if the external firewall blocked any external connections)

And would I maybe want to deny all raw tcp/udp but allow email (as per above? )

The flag is just informational about the node-red environment it would still be up to the node developer to decide what to do with that information.
The intention is to indicate environments where there is only http (hostname based) access, but it will be up to the admin deploying Node-RED if to set this or not.

In terms of localhost I think that would always be allowed but again this is up to the node developer, if the node just listens on localhost they may not even consult the flag.

The email example I was using was that it listens on port25 as an SMTP server, so although it doesn't explicitly say in the node that its a TCP server the developer would know that it is.

The main requirement is a way to disable (non-http) inbound connections in the core nodes. We have other ways of disabling/blocking extra modules that can be done administratively (and doesn't require the node author to had adopted this setting).

The scenario of allowing some connections but not others is out of scope of what is being proposed here.That would require the node UI to allow inbound to be configured, but then have additional validation to allow only certain values.

ok - so more of http(s) connections only flag.

Aha - as Nick just said - "disable (non-http) inbound connections"

So does this just disable them ? or stop them appearing in the editor palette (IE can't be used) ? EG if I import a flow with existing (or new) tcp in node in - will it somehow get disabled (dotted) ? or be "unknown".
(I'd assume the actual cloud instance would stop it actually working/doing anything so no danger per se - so purely visual)

or stop them appearing in the editor palette (I

The problem we have is the TCP nodes can act in both inbound and outbound mode - we don't have separate nodes for the different 'directions'. So it isn't just a case of disabling a node (which we could already do). The purpose of the flag would be to tell the TCP/UDP nodes not to offer the inbound configuration options.

In terms of importing a flow with a node configured for inbound connections - the node validation logic in the editor would be able to flag it as an invalid configuration.