To me, this looks like more of a cludge or stop gap until libphobos is set to be built as a shared library by default.
And having a look up on the behaviour of the flags, it seems that building with -ffunction-sections/-fdata-sections will generally create larger binaries unless one remembers to always compile with --gc-sections. Ugh.
I certainly appreciate your (and everybody elses) work on this, and hope shared libs happen sooner rather than later.
But it's not as simple as making the dlls build. Can you imagine somebody shipping a (binary) product linked to a shared system D runtime (phobos etc) in three months time? Half a year? Two years?
Because if it can not use system provided libs, it might just as well be linked statically; in fact doing this avoids a lot of problems, for which the only solution would be "make sure the very library we shipped you is used" anyway.
Is phobos stable enough that you can rely on the dll ABI not changing for the lifetime of the product? Being included in every relevant distribution/OS, with all of them being compatible?
How many versions of the dlls will there be? IOW, will you have to pick one of llvm, gdc or dmd variants? Support all of them?
The problem may be a little smaller for source (or pseudo-source, such as ubuntu etc) based distributions, but it is still there. I imagine the windows way would be a bundled dll with every single D app anyway, so that doesn't impact much.
My point is just that statically linked D programs  will be relevant for quite some time yet, and the "stop gap" would be useful even long after shared libs became officially supported. Hence the multi-year estimate above.
Is there any technical problem with the per-function|data sections approach? The few tests i was able to run here didn't turn up anything, other than the huge difference in executable sizes. (First thing i was worried about was the possibility of the D GC being confused by data/bss layout changes, but things seem ok so far. Normal (ie. w/o ld's --gc-sections) linking seems to work reasonably (same number of sections in the resulting executable, similar size)
 well, "programs statically linked with phobos", as the issues with other (common) libs are not much different from Cs.
2) The phobos library shipped with GDC is to reside in the GCC library directories, so is not to be confused with system libraries. Generally, you release a binary, you say it requires GDC runtime library version 4.x.x to run. It is not assumed that mixing libraries between DMD, GDC and LDC will work, due to ABI differences, but with the issue you raised on library variants, this is only an issue if you ship libraries as a standalone package/install. Applications on the other hand will have no such problem as they tend to ship their own dependencies in their own library directories.
1. resulting executable is already doubly bloated, so if one doesn't care about size, he may not care about forgetting --gc-sections. It should be also solvable with compiler config, right?
2. shared and static linking serve different purposes and have different tradeoffs (like distribution and maintainability issues). Static linking will always have sense, so ideally both options should be available (just like for c++ libs). This proposal improves static linking and seemingly doesn't break shared one.
3. shared linking has even worse size issues because nothing can be omitted from the library.