I think the summary is a bit confusing here. /etc/profile.d is a directory, so this definitely shouldn't be marked as %config.

But if I get it right, you propose to have this tracking bz - and check all existing profile.d scripts for %config macro. In addition, you propose to have defined order of the profile.d scripts execution. As you can see in https://git.fedorahosted.org/cgit/setup.git/tree/profile on line 65, this can be easily solved by modifying "for i in /etc/profile.d/*.sh ; do" with "for i in $(ls /etc/profile.d/*.sh | sort) ; do" (or something similar with less overhead than ls ;) ) - so you will have defined order of the profile.d scripts sourcing. Of course, having /etc/profile.d/sh.local and source this after all *.sh scripts is another alternative...

Can you confirm this is basically what you expect from this bugzilla ? What solution do you prefer?

Yes it would the files in the directory. I think I did not made
if much clear because I did not fully describe implications, of
likely too many packages owning files there.

I think ls | sort may depend on locale, while starting with a
numeric value is unlikely, but would require sort -n.

The idea of sh.local is kind of to match rc.local :) Just have
a placeholder for the user to try to fix or override system
settings, and does not end in .sh to not match the pattern of
the files to be sourced.

ls | sort can be made locale independent with LC_ALL=C (I would do that anyway, as mb path of sort is much slower). However, maybe the sh.local is really better idea. I'm fine with that addition. 

Looking at the repofile from 7.2, there is not that many profile.d scripts shipped by RH (with packages where the files are):
/etc/profile.d/PackageKit.sh:PackageKit-command-not-found
/etc/profile.d/abrt-console-notification.sh:abrt-console-notification
/etc/profile.d/bash_completion.sh:bash-completion
/etc/profile.d/colorls.csh:coreutils
/etc/profile.d/colorls.sh:coreutils
/etc/profile.d/cvs.csh:cvs
/etc/profile.d/cvs.sh:cvs
/etc/profile.d/modules.csh:environment-modules
/etc/profile.d/modules.sh:environment-modules
/etc/profile.d/colorgrep.csh:grep
/etc/profile.d/colorgrep.sh:grep
/etc/profile.d/256term.csh:initscripts
/etc/profile.d/256term.sh:initscripts
/etc/profile.d/lang.csh:initscripts
/etc/profile.d/lang.sh:initscripts
/etc/profile.d/kde.csh:kde-settings
/etc/profile.d/kde.sh:kde-settings
/etc/profile.d/less.csh:less
/etc/profile.d/less.sh:less
/etc/profile.d/guestfish.sh:libguestfs-tools-c
/etc/profile.d/mc.csh:mc
/etc/profile.d/mc.sh:mc
/etc/profile.d/gnome-ssh-askpass.csh:openssh-askpass
/etc/profile.d/gnome-ssh-askpass.sh:openssh-askpass
/etc/profile.d/perl-homedir.csh:perl-homedir
/etc/profile.d/perl-homedir.sh:perl-homedir
/etc/profile.d/qt-graphicssystem.csh:qt-settings
/etc/profile.d/qt-graphicssystem.sh:qt-settings
/etc/profile.d/qt.csh:qt3
/etc/profile.d/qt.sh:qt3
/etc/profile.d/qt.csh:qt3
/etc/profile.d/qt.sh:qt3
/etc/profile.d/vim.csh:vim-enhanced
/etc/profile.d/vim.sh:vim-enhanced
/etc/profile.d/vte.sh:vte-profile
/etc/profile.d/which2.csh:which
/etc/profile.d/which2.sh:which

However, I think missing %config option is probably something what you can expect from 3rd party rpms. And I haven't checked these above listed files for it, yet...

Thinking a bit more about the issue, sorting can potentially break existing setups (where it worked by miracle). Therefore for 7.5 going only with adding the sh.local file and running it. It should resolve the issue - as admin would be able to override settings from previous /etc/profile.d scripts.

Added test for the new feature and verified by re-running whole test suite.  Looks fine; results as expected.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1015