DEPR: keep_date_col, nested parse_dates in read_csv
- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Thanks @jbrockmendel  What is the rationale for deprecating datetime parsing on combined columns? That's something I personally use a lot (CSV being what it is, date, time of day and timezone offset are often stored in separate columns), and I've not seen equivalent code examples that would achieve the same thing at parsing time. > I've not seen equivalent code examples that would achieve the same thing at parsing time.

Internally pandas didn't do this at parsing time. `read_csv` would combine parsed columns and use `to_datetime` essentially with these options. You can achieve the equivalent by using `.str.cat` with `to_datetime` @mroeschke: Using `to_datetime` is fine for a flat dataframe, but it gets [increasingly complicated](https://github.com/pandas-dev/pandas/issues/50601#issuecomment-1376293705) as indexes and multi-indexes get tossed into the mix. No longer being able to specify those things in the read_csv config so I don't need to think about these afterwards wouldn't be the end of the world, but it's an extra bit of boilerplate index manipulation for some very common situations that I don't currently need to think about, and may pose problems for inexperienced users.