I've put together our own proposal over here: https://github.com/node-red/node-red/wiki/Design%3A-Dynamic-MQTT-node
It tries to address a wider set of requirements than just your scenario.
It introduces a third node - an mqtt-control node that can be used to control the behaviour of the associated mqtt-broker node. The node has both an input and an output. Passing that node different control messages will cause the broker node to connect, disconnect, subscribe, unsubscribe and publish. The 'connect' action allows you to provide alternative broker details.
The mqtt-broker node will have a new option to not automatically connect (similar to what you propose). That will allow the flow to completely control when and how it connects.
You wouldn't have to use it to publish messages - you could still use an MQTT Out node configured to use the same mqtt-broker node. Likewise subscriptions (if the scenario allows for a hardcoded subscription as the nodes provide today).
If you need to be able to dynamically subscribe to a topic identified at runtime, the mqtt-control node will have an output to send any messages received due to subscriptions it has created. There's an open question on whether it would pass through all of the other flow messages it receives.
To achieve the 'connect, subscribe, get one message, disconnect' behaviour you would need a bit of flow logic around the node to pass it the appropriate control messages needed. That's my preference for version 1 of this node - want to get the basic functionality right first and gather feedback on it before we think about baking in other patterns of behaviour (if at all).
