Potential clarifications:

• If Petersburg and Constantinople are applied at the same block, Petersburg takes precedence: with the net effect of EIP 1283 being disabled.
• If Petersburg is defined with an earlier block number than Constantinople, then there is no immediate effect from the Petersburg fork. However, when Constantinople is later activated, EIP-1283 should be disabled.

Isn't it easier to state Petersburg can only be applied after Constantinople, with the one exception of activating at the same time, then Petersburg takes preference?

I agree with @axic It will better if we can set Petersburg block number >= Constantinople

It makes it unnecessary complicated. The clarification Martin proposed clearly states how a client should behave if Petersburg < Constantinople.

I beg to differ. With allowing Petersburg before Constantinople the client must track a flag, while my proposal would allow the client to just reject starting after parsing the block numbers in the configuration.

Well, the flag needs to be tracked regardless. With the proposed solution, we don't have to add an extra constraint when validating the configuration. It also makes it easier to manually/semi-manually create configurations, since you can set the petersburg block to 0 and don't worry about moving that one around if you move constantinople.
Also, geth has override.constantinople flag, which would continue to work nicely (and I'd recommend Parity to implement it too). If we change like you propose, the user would have to override both.

Wouldn't it be better to specify it that Petersburg activates EIP 145, 1014, 1052, 1234 and disables 1283?

No, Constantinople enables EIP 145, 1014, 1052, 1234, and 1283; Petersfork disables 1283. I don't see why we should have two hardforks for the same thing.