The correct way to generate a CSV cell with a leading 0 is
="01"
01,"01",="01" ="01"
01,"01",="01"Excel may predate the RFC but AFAIK MS didn't invent or coin the term CSV, so you can't just say whatever Excel does is correct. The RFC is loose because of nonsense like this, it doesn't mean it was ever a good idea.
But none of that is really the point. Because CSV files aren't just for importing into Excel. One of their main benefits is their portability. In other situations column types might be specified out of band, but even if not, putting equals signs before values is unconventional, so more likely to hurt than help. And in the cases it might help, i.e. when you only care about loading into Excel, then you have options other than CSV, rather than contorting CSV files for Excel's sake.
> What ever happened to process and a sense of responsibility and craft in your work?
I actually have no idea what you are on about. I'm talking about the "responsibility and craft" of not producing screwed up CSV files. Why do some people find that so offensive? Yes, it is not inconceivable that there could be some situation working with legacy systems where putting `="..."` in CSVs is, unfortunately, your best option. Sometimes you do have to put in a hack to get something done. But don't go around telling people (or yourself) that it is "the correct way".
As for the actual RFC, it's worth taking a read. Any sort of value interpretation is left up to the implementation, to the extent that Excel's behavior in interpreting formulae is 100% in compliance with the spec.
Anyway the RFC doesn't mandate any value interpretation IIRC.
If Excel were the only intended consumer, .xlsx would be a preferable file format. At least it's mostly unambiguous.
I actually wanted a CSV file – preferably without having to resort to sed to strip out excel formulae.
For all the other uses in the world, that's a breaking change.