No, I realize that from a practical point of view it would be nice to have something that often just works, but we have deliberately designed it this way because it has a very clear scope and by not stepping outside that scope for practicality’s sake, people are more likely to learn early on that they are using the function incorrectly (i.e. for parsing datetimes not guaranteed to produce only the formats that datetime.isoformat produces).
The preferred solution is to have a version of this function that will satisfy both the people who want to invert datetime.isoformat and the people who want to parse ISO 8601 datetimes in general. I think Petr’s suggestion of leaving the feature flags for dateutil.parser.isoparse and creating a liberal ISO 8601 parser might simplify things greatly, however.
In the meantime, I have seen no objections to using dateutil.parser.isoparse other than “but it’s in a third party library”, which is not a great justification, particularly when that library is dateutil - an incredibly popular library maintained by one of the maintainers of datetime (me) and from which datetime.fromisoformat was adapted in the first place. Best case scenario, we change the scope of fromisoformat today, PEP 602 passes and you can get the same functionality you get out of dateutil.parser.isoparse today in November 2020, assuming you are comfortable immediately upgrading your code to be Python 3.9-only. Given that timeline, I don’t think there’s enough urgency here that we should complicate the clearly-communicated scope of this function with a half-measure like supporting parsing “Z” for UTC.