systemd-coredump (or, rather, journald) ignores the split between system accounts and user accounts as configured in /etc/login.defs ("the authoritative definition of UID/GID space allocation", according to the Fedora wiki) and instead hard codes 1000 as the split*.

The end result is that when systemd-coredump enabled, unprivileged users cannot access their own core dumps. (Or any of their own logs in journald.)

This means that if you are a loyal Fedora user that initially installed before the change from 500 to 1000 (Fedora 15 or earlier) and have been faithfully upgrading from release to release, enabling systemd-coredump by default in Fedora 26 will be a regression in functionality.
(Obviously, systemd is also broken if your organization has a need to change the SYS_UID_MAX definition in /etc/login.defs for some reason.)

systemd-coredump should not be enabled by default in Fedora until this bug is fixed by the systemd developers.

Note that the systemd developers deny that this is a bug and are adamantly opposed to the idea of fixing it, so this change should never be enabled.

Fedora bug was: https://bugzilla.redhat.com/show_bug.cgi?id=1401772
Upstream bug was: https://github.com/systemd/systemd/issues/3855

*: It's actually more egregious than that: /etc/login.defs is parsed on the build machine at compile time and the extracted value is hard coded into the various systemd executables which then completely ignore /etc/login.defs at run time.

In the 2016/12/16 FESCo meeting, this change was approved, given that the systemd folks solve the SELinux issue that is currently keeping it from working.