When a user changes a violation_error_message on constraints it unnecessarily causes a remove/add operation in migration. I opened up a PR with a patch, where I created a method within the BaseConstraint class that returns a copy of the Constraint object without the two fields (violation_error_code and violation_error_message) that do not affect the DDL. I then call this method in create_altered_constraints and use that to determine when a migration for constraints is truly necessary.
@charettes chimed in on the PR and mentioned that this method breaks with the existing pattern in the migrations code: "It seems like we should have an AlterConstraint operation that is in charge of dealing with that but it doesn’t exist already 
This one is really a pickle, I can see the appeal to do away with discarding some attributes to avoid introducing AlterConstraint for the sake of supporting these options but it makes this code alien to the remaining of the migration code base; it’s not only the auto-detector that cares about deconstruction and equality.
Maybe it’s time to revisit the discussion around not support constraint alteration in the first place".
So I wanted to post here in the forum so we can open up the floor for discussion and decide what the best path forward is for this ticket.