After some experimenting, and stumbling across “what is NSLayoutConstraint “UIView-Encapsulated-Layout-Height” and how should I go about forcing it to recalculate cleanly” I determined that you can circumvent this problem using either “Height” & “Equal Heights” OR “Height” and Top and Bottom “Vertical Space” (as suggested by Guilherme Sprint), and then decreasing the “Priority” of the height constraint to 999.
This isn’t the answer I was hoping for, but it does specify the height of the container via Auto Layout of the subview and avoids any warnings about broken constraints.
My entirely unscientific guess/assumption/conclusion is that iOS is correctly looking at the layout constraints to determine the height of the container view. It then adds a new constraint that is the same height as what it just calculated, but this now over-constrains the height. Reducing the priority on the original developer specified height constraint means the system generated constraint wins out and no warning is generated (would love to hear more about this from someone who actually knows).