I've commented on the ticket with a use case that explains why this might be plausible.

I'll agree that if we *do* relax the level, the message needs to be clarified to a "must be unique, or part of a unique_together clause".

Also, as I noted in the ticket, this isn't *removing* the constraint -- it's relaxing it to a "warning" status instead of an error. The intention is that errors will stop commands like runserver from running; warnings will be printed, but not stop anything.

However, there might be another way to treat system check messages. I mentioned in a different review comment that one of the goals for this project was to associate codes with all error/warning messages. The intention for this was to allow certain messages to be filtered out in the same way that you do with PyLint/PyFlakes i.e., if you don't care about long lines, you can silence E501 warnings, and they won't get picked up.

Using this feature might give us a way to satisfy your concerns. Lets say any message more severe than "info" will stop runserver etc from running. However, anything at a warning level can be suppressed by either passing in an argument, or by putting the code in a project setting ("ACKNOWLEDGED_CHECKS"). This would mean this problem would still be caught by default, and would still stop you from running syncdb/runserver; but if you wanted to take a strategic risk and work around the warning, you'd have a way out.

Thoughts?