1. About skip connection replace
This is very good question because it touches a particular MQTT behavior related to connection replace when connecting for second time using same credentials.
This is useful to protect devices from been blocked by stalled connections due to NAT problems.
However, as you have noticed, it creates problems in environments where the same clientId+userName is used to connect (and subscribe) and to PUBLISH.
It also creates problems with integrations where same user/credentials are used to publish several messages at the same time in a concurrent manner. For example, a web page triggering PUBLISH by every visit. It is likely several visits can happen at the same time.
As you can see it has pros and cons. Now, to solve the issue you can:
Use different users to publish and subscribe, paying attention not to reuse them (only one time per credential).
Or, disable “Connection replace” so you can connect several times without closing previous connection.
2. How to avoid connection replace: enable skip connection replace
If you opt for second option, here is how. Go and click on the device where you want to skip connection replace:
After clicking and enabling “skip connection replace”, save device options.
3. Some notes about disabling connection replace
It is not standard
Every device connected with these credentials will receive a virtual temporal clientId with cleanSession enforced to true (subscriptions will be lost for example, so you have to resend them).
Devices connected with skip connection replace on will have no support for unconfirmed messages storage ( see “showing and cleaning unconfirmed messages”).