When using the dnf package payload in the installer (recent Rawhide composes), the environment groups are ordered exactly as they appear in comps-f22.xml.in - not according to their display_order values. This means the default env group is Fedora Cloud Server, as that's the first listed environment.
When using the yum payload - booting with 'nodnf' - the display_order values are respected and Fedora Server is the default environment group, as expected.
The installer does not appear to do any of the comps processing work itself, but with the dnf payload it will be using libcomps, not yum's comps lib, so filing against libcomps.
Note also that 'dnf group list' shows the available and installed groups in alphabetical order, but 'yum group list' respects the display_order values.
This is a high priority bug as it will result in the wrong package set being the default for the Server network install image. This should probably be a Beta or Final blocker, but we don't appear to have a criterion that would cover it. I'll draft one. Proposing as an Alpha Freeze Exception for now.

Hi
Libcomps doesn't modify order of groups in input comps file, thats why it could be different from groups ordered by display_order attribute. First group in comps.xml file is first group in comps.groups list.
I think this is more dnf issue than libcomps. Libcomps is more like library providing functions for comps manipulation rather than high-level 1:1 API for strictly dnf purpose.

dnf.comps.Comps.groups/group_by_pattern/groups_by_pattern and dnf.comps.Comps.environments/environment_by_pattern/environments_by_pattern DNF API methods are ordering groups by `display_order` in this PR. Ordering is honored in `dnf group list` output too.
[1] https://github.com/rpm-software-management/dnf/pull/193