Consider changing the way values are flattened before passed to the CSV Encoder to provide better data per column

I'm uploading a patch that leverages the idea @Berdir pointed-out.

It works quite nice IMHO... However, some fields needed special handling, so I implemented it for entity_reference, link and datetime field types for now.

The patch was based on top of #2853480: Expose export helpers through a service (#11).
The interdiff above represents the actual changes between this issue and #11.

Correct patch directory.

+++ b/modules/contrib/contact_storage_export/src/ContactStorageExportService.php
@@ -58,171 +72,157 @@ class ContactStorageExportService implements ContainerInjectionInterface {
+        default:
+          // Display a field item value using default field formatter.
+          $renderable_array = $item->view();
+          $values[] = $this->renderAsString($renderable_array);
+      }

wondering if we want to do something like token.module. Support a contact_storage_export view mode that you can enable and configure per contact form and fall back to the default settings. Also, don't we get labels if we do it like this, or are you working around that by rendering each item separately?

See field_tokens()

Created followup for #6: #2856956: Improve export configurability with a custom view mode

In #5, I removed date_format setting and used default field formatter setting instead.
Since this setting is available on the Export Form, I reverted the changes and made all date-like (datetime, created, timestamp, daterange) fields consider date_format.

Re 8.x-2.x. that's up to you, we'd be OK with that.

It is maintenance overhead, especially if you plan to maintain both versions (for how long?) Or would you just use the major version switch to clarify to users that there are changes and stop supporting 1.x soon-ish?