My first point is, I suppose, that a date like '3/10/2020' is almost never ambiguous. Not to the user (because of custom) and not to the user's Windows system (because of locale).
The only time a date is ambiguous is if there is no such context. And in that case, a date like '3/31/2020' is also ambiguous. It is either 31 March 2020, or (as it would always be in New Zealand, and in most of the world) wrong. Without context, who knows?
Manifold should not see it as ambiguous either. It should either know or throw, never guess.
Secondly, a case-by-case approach is not good enough. It is no good if successive dates in a table, stored in text format, are interpreted with opposite day-month order on parsing. That is worse than useless and dangerous.
Third, there are at least two more important contexts, besides CSV. One is manual data entry, the other is parsing SQL literals. These should follow defined rules, aligned with user culture, and be consistent from one date to the next. (And throw a type error if a supplied date makes no sense in the current culture, even if it would in another.)
Fourth, even if it is necessary to store all dates in one format, it must be possible to show them in a format valid for the user.
Yes, it would be good to be able to specify the exact date format as well, even going against applicable custom/locale (useful for writing code across borders). But that is not enough to solve the problem or be safe.