Marathon enforces uniqueness for service ports; however, the constraint only considers the current target state, and not the former state for some ongoing deployment. Furthermore, rolling back a deployment, understandably, does not trigger validation. As such, it is possible to put Marathon in an invalid state, where 2 apps share the same servicePort.
Marathon tries to assign unique service ports when servicePort: 0 is provided, but when assigning, it only considers the current target state for some ongoing deployment. This means that when we roll back a deployment it is possible for a unique service-port assignment to no longer be unique.
Further, since there is no global validation for service port uniqueness, one can simply post the two app definitions with the same service ports, and Marathon will accept them.