Anyone else having the 'helpful' regex that breaks existing input validation?

I've been conducting a detailed review of several recent code assistance sessions, specifically around the generation of input validation logic, and I've noticed a concerning pattern. The assistant often proposes a "more robust" or "helpful" regular expression for validating common input types like email addresses or phone numbers. The issue is that these regex patterns, while perhaps more technically comprehensive, frequently break existing, perfectly functional validation by being overly strict, or by introducing boundaries or character classes that reject previously accepted, real-world data.

The most common failure case I'm seeing is with email address validation. A developer will have a simple, pragmatic regex that works for their application context. The assistant, aiming to be helpful, suggests replacing it with a famously complex, standards-compliant regex. This new regex, however, often fails on valid internationalized domain names (IDN), quoted local parts, or even certain perfectly valid but non-obsolete characters. The result is that existing user data in the production database suddenly becomes "invalid," causing login failures, profile update errors, and support tickets.

Here is a concrete example from a code review I was auditing:

**Existing, functional validation (simplified):**
```python
import re

def validate_email_original(email):
# Simple pattern: local-part @ domain . tld
pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$'
return re.match(pattern, email) is not None
```

**The 'Helpful' Suggestion:**
```python
def validate_email_suggested(email):
# A "comprehensive" RFC 5322 compliant regex (abbreviated for example)
pattern = r'^(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[x01-x08x0bx0cx0e-x1fx21x23-x5bx5d-x7f]|\[x01-x09x0bx0cx0e-x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])).){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[x01-x08x0bx0cx0e-x1fx21-x5ax53-x7f]|\[x01-x09x0bx0cx0e-x7f])+)])$'
return re.match(pattern, email, re.IGNORECASE) is not None
```

**The Breakage:**
* The original regex would accept `user.name+tag@example.com` (a common practice for mail filtering). The suggested regex *might* accept it, but many simplified "comprehensive" versions found online do not handle the `+` in the local part correctly.
* The original is case-insensitive for the alphabetics in the domain part. The suggested one, even with `re.IGNORECASE`, has complex character classes that can fail on mixed-case input.
* The sheer complexity of the new regex makes it a maintenance burden and a potential source of subtle bugs (e.g., catastrophic backtracking) if not used exactly right.

The correct answer, from a compliance and operational risk perspective, is not to blindly replace a working validation with a more complex one. The audit-logged, correct process should be:

1. **Analyze the existing data:** Query the user database to understand the actual email formats already accepted and in use.
2. **Define requirements:** Does the application need to support internationalized email? Just basic commercial domains? The validation should match the business need, not an academic standard.
3. **Use a dedicated library:** For languages that support it, the correct answer is often to use a well-maintained, peer-reviewed library for validation (e.g., `email-validator` for Python) instead of a hand-rolled regex.
4. **If a regex is necessary,** the change should be:
* Tested against the existing production dataset.
* Rolled out with a migration plan for any now-invalid data (which is often zero if the regex is chosen pragmatically).
* Documented in the change log with a clear rationale.

Has anyone else audited their logs and found similar instances where an assistant's "improvement" to input validation logic inadvertently introduced a regression or broke compatibility with live data? I'm particularly interested in cases involving phone number formats, postal/zip codes, or date parsing, where local conventions are often sacrificed for a "one-size-fits-all" regex.