@Steve-Mcl, Use case:
in a__flow: global.set("user_defied_config", "foo"); (e.g. using node-red-contib-config, works in 'On Start').
in b_flow: my_subflow( "@global.get('user_defined_config')" ) ( replaced by 'foo' )
desirable alternatives: my_subflow( [global.]user_defined_config) my_subflow([J:]$globalContext("user_defined_config"))
in c_flow: my_subflow( "bar" )
@knolleary thanks, clear argument, but for me it is not a case of dynamic evaluation, but of (quasi-static) indirect definition.
Or not? i.e. the unique solution is my workaround? (it allows a dynamic evaluation).
Why not insert some new code into the subflow interface, to also accept [global.] [flow.] [J:expression] [timestamp] ?
Similar limitations are present in many "contrib" nodes, where the programmer too often just uses [text] .
In conclusion, the limits imposed on the subflow, if they are a deliberate choice, are unreasonable and harmful.