As discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1656509 , it seems to be generally the case that any upgrade which involves modular content will not work correctly unless the 'module_platform_id' option is explicitly set to the correct value for the target release. e.g. when upgrading to Fedora 30, this is needed:
sudo dnf system-upgrade download --refresh --releasever=30 --setopt='module_platform_id=platform:f30'
It was generally agreed by the Modularity WG and others (including QA) that this is not acceptable: upgrades should work as they did before modularity, i.e. only --releasever should need to be passed.
I'm setting the version here to 29, but in fact I suspect we should put the fix in all active branches (including F28) so upgrades from F28 to F30, for e.g., work?
Proposing as an F30 Beta blocker, but I suspect we may decide to make this a Beta FE and a Final blocker (on the basis that it might be OK to ask people to do the --setopt for a Beta, but not for a final release).
Maybe it's time for specifying an upgrade path between module streams. platform:f29 is unsupported in Fedora 30. Thus Fedora 30 modular repository should specify that platform:f30 replaces platform:f29. With this metadata available DNF could switch the stream automatically on system upgrade. Something like Obsoletes in RPM. This feature should be available for all modules. Not only platform. Because other modules' streams are also subjects of becoming end-of-life.
Discussed during the 2019-03-18 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker (Beta)", a "RejectedFreezeException (Beta)", and an "AcceptedBlocker (Final)" was made as we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change.