systemd-coredump in distros

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

It seems common for new distros to install systemd-coredump by default
and disable core files in the current working directory.  For instance,
see the announcement "Enable systemd-coredump by default" for Fedora 26
(https://fedoraproject.org/wiki/Changes/coredumpctl).

Is there a recommended/preferred way to deal with this in a typical
development use case?  I stumbled upon some issues with systemd-coredump
and don't know if I misunderstood something:

* In my tests, after invoking a command that dumps core, it could happen
  that "coredumpctl" failed immediately afterwards and succeeded a
  second later -- maybe due to asynchronous processing?

* There does not seem to be a way for a user to remove core dumps from
  the journal.  Thus a developer's experiment may pile up dumps in the
  journal, occupying lots of space and making the dumps more difficult
  to find.

* I've seen dumps (from GDB's bigcore.exp) being truncated by
  coredumpctl down to four Gigabytes, although no such limit was set in
  /etc/systemd/coredump.conf.  Note that I haven't investigated where
  the truncation happens.

Considering these issues I wonder whether there's a way for a user to
tell systemd-coredump something like: "Core dumps from this process
should be treated traditionally and written to its current working
directory".  Is that possible?  If not, should it be?

--
Andreas