Because noone so far came with some solution suitable for all situations... /etc/mtab is what df uses and as it is symlink to /proc/mounts , this is the only information df has. There were several approaches to this problem, none of them is perfect.

it was not a symlink for about 15 years
so maybe such changes should be introduced if they are ready

even in PHP i could write within 10 minutes a script parsing the outputs starting in https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c11 but sadly "coreutils" are not written in PHP so i can't fix them

I haven't introduced the mtab symlink - you know who did... but it was done, so not much to do now.
Coreutils are written to be portable ... this is the main reason why we can't do hacks for Fedora only. Some ugly hack can be written in several minutes, but it will work only on all machines (setups may differ)... and most importantly - most probably will not be acceptable by upstream.
When we had duplicates, people complained, for shortest one device name people complain, first come first serve - people complain - I really don't see any magic solution working for everyone.
The only way would be to write new, linux specific part in gnulib mountlist module, probably inspired by util-linux submounts solution - this way can be identified the main mount. No way how to get the information from /proc/mounts file. As util-linux differ from coreutils style a bit, it could be quite difficult task.

> When we had duplicates, people complained

because it is unacceptable on a server with some hundret bind-mounts becauseo one is using openssh's sftp-chroot to replace FTP, i was th eone complaining

> for shortest one device name people complain

because it is wrong

> first come first serve - people complain

who complains here?

the first one *non bind-mount* is the primary device
in case of "df" == disk free i want this one, only once
not a random bind-mount *using* that one in /etc/fstab

treating my /mnt/data as /tmp in df-output is questionable to say it polite sicne /tmp is a bind-mount to /mnt/data/.tmp and i am for sure not the only person acting this way to prevent from TmpOnTmpfs in case of machines with no need for a dediacted /tmp-partition and not want it on rootfs for well known reasons

> Coreutils are written to be portable

that's fine - but IMHO the job of a *distribution* is to give a useful behavior for it's core commands - in Fedora 18 this was done right and from Fedora 19/20 to RHEL7 it is broken again, well not that broken as in Fedora 15 with listing all bind-mounts but still a step backwards from F18 behavior

> I haven't introduced the mtab symlink - you know who did

kernel upstream, but i am pretty sure they did not expect that userland-software like "df" is rocket science not able to cope with it beause all needed system informations are present and kernel-upstream has it's focus on Linux

(In reply to Harald Reindl from comment #5)
> who complains here?
> 
> the first one *non bind-mount* is the primary device
> in case of "df" == disk free i want this one, only once
> not a random bind-mount *using* that one in /etc/fstab

https://bugzilla.redhat.com/show_bug.cgi?id=709351#c31

There started the way of "first come, first serve" - which worked for the bind mounts quite well, but had other issues...

I meant the way to "silicon heaven"... later on, on upstream mailing list, the current approach was chosen as the "best one". Still - it doesn't work correctly for some types of bindmounts...

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

well, can we have this fix for Fedora too where this issue exists for years now with a short timeframe where it was fixed

/dev/md2 is *not* /tmp

/mnt/data/.tmp               /tmp                                    none  bind
/mnt/data/.tmp               /var/tmp                                none  bind


Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/md1       ext4   29G  6.5G   23G  23% /
/dev/md0       ext4  485M   37M  444M   8% /boot
/dev/md2       ext4  3.6T  2.1T  1.5T  60% /tmp

The comment above is incorrect. The correct version is bellow.
I'm sorry for any inconvenience.
---------------------------------------------------------------

This request was NOT resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you need
to escalate this bug.

Note this is now fixed in Fedora.  See bug #1001092 for details.

*** Bug 1261032 has been marked as a duplicate of this bug. ***

*** Bug 1450229 has been marked as a duplicate of this bug. ***

*** Bug 1650045 has been marked as a duplicate of this bug. ***

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-2019:2217