Sorry, But in this case you have misunderstood (or forgotten) a detail about the MQTT data publication sequence...Try to understand the MQTT concept before implementing something which does not fit.
If (for some unlikely reason) the QOS1 publish from Rocrail is NOT received by the Broker, RocRail needs to resend the Publication.
As you say, the MQTT Broker deals with the message but can only do this once it has received it. after this, the Broker will deal with any resends to the clients if and when they are necessary.
But, if the message is not properly received by the Broker, it cannot send it on!
I only make this point because, as you pointed out a long time ago in this conversation, you chose QoS1 for totally reliable communications, and therefore I can see that to achieve this you need to allow for the (unusual!) case where a Rocrail message to the Broker is lost, and I had assumed that your would have done this.
If you do not do this, very occasionally publications from Rocrail may be lost, and points not set, or locomotives not started / stopped... Such errors will probably be very rare, but are not totally unknown.
For my WiFi connected node, a loss when sending to the Broker is probably much more likely than when Rocrail is sending to the Broker, so I am just finishing off adding QoS1 PUBACK checks for when I send sensor event stuff to the Broker.
If we are trying to have the best performance and no communications loss, Rocrail should really check it gets the correct PUBACK for each publication, and then resend if needed.
I hope we are still friends?