+1^10 for layering an 'easy to use' DSL on top of an existing 'Tried and True' mature CSV library.
"CSV" is netoriously subtle -- ("Quoted" as the subtly is a lack of specification and lack of conformance to specificiation 'in the field'). I encourage you to not underestimate the range of common 'real world' difficulties with csv and to not lump in libraries that have grown to handle these real issues with 'users don't need highly functional libraries'.
While the issues tend to be combined, such that its not obvious what are 'fancy but unnecessary' features vs '^You really dont want to know WHY we had to do this -- but trust me, you need it '
I encourage you to focus on the value add your library exposes (the 'Simple DSL Use Case') but to wrap that on top of (possibly pluggable) mature CSV library(s).
Why pluggable ? The 'native' disusision is relevlent, but even on JVM there are reasons for programs to try to stick to one 'family' of data serialization/parsing/data mapping where possible.
One example: consistent mappings of column headers to data field/property names, and consistent ways to configure things such that they can interop.
For example, Im working on an app that has to read and write externaly-defined CSV files. (actually TSV)) ..) I also need to data-map these into Kotlin classes to expose to internal business logic as well as 3rd party tools (such as GUI and DB)
It is an incredible pain to get consistant treatment end to end of 'simple' things like column headings like "Record Number"
More subtle issues -- are TSV files (tab csv) to include or not quoted values? Are the order of headers reveleal (can they be detected out of order for reads? what about writes? can they be remapped?) Do read and write have to produce identical content ? or simply logically equivalent content? Can schema be used for data validation ( (like csv-schema ), can the data be queried by column name ? Can there be additional or missing colujms ? Are empty values nulls or "" ? Are values typed ? ( i.e can are invalid numbers rejected or passed), are escapes used ? if so what style ? Can embedded newlines be present ?
These are only some of the issues. If you look into the checkin history of any major CSV library you can see the history of pain solved bit by bit.
For an library authors' perspective -- I would highly recommend against writing your own parser for any general purpose case.
For a library consumers perspective, I would stay way from any CSV library that was not based on a older/mature co-debase -- regardless of additional value ... its not worth the risk. (past 30 years is paved with multiple nieve attempts at "This one should be good enough" ..))