My apologies once again, I was just trying to recap the prior discussion. There are several things going on here.
# Issue 1: .group sections are not discarded
I think your example is appropriate for the .group issue. This scaled-up version is an absurd example...but you asked for detail and it simulates what can happen with a larger codebase. 
$ cat ldscript.amd64
SECTIONS
{
.rela.text : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) }
.text1 : { *(.text .stub .text.* .gnu.linkonce.t.*) }
}
$ cat sections.sh
#!/bin/bash
for i in {0..65280}
do
echo -e "inline int inline$i() { return $i; }" >> a.cc
if [[ "$i" -gt "0" ]]; then
echo -e "int use$i() { return inline$((i-1))() + inline$i(); }" >> a.cc
fi done
clang -c a.cc
ld.lld -r -T ldscript.amd64 a.o -o lld.ro
$ ./sections.sh
$ readelf -h lld.ro
[...]
Number of section headers: 0 (65293)
Section header string table index: 65535 (65291)
Because of the incredible number of .group sections, the object becomes a problem for code that does not correctly handle a section count > 0xFF00:
> If the number of sections is greater than or equal to SHN_LORESERVE (0xff00), e_shnum has the value zero. The actual number of section header table entries is contained in the sh_size field of the section header at index 0. Otherwise, the sh_size member of the initial section header entry contains the value zero.
> ELF Header (Linker and Libraries Guide)
Yes, one can wish all of that code was updated to ELF spec. But some of that is outside our control, and the problem here is artificially introduced: there aren't that many sections generated from either the code or the linker script. It's just the detritus created by the assumption of further linking of the output, which is (I believe) why Peter proposed an indicator that the output is intended to be final (and presumably the .group sections would be processed as they are for shared objects).
In this case, ld.bfd -r creates more sections than ld.lld -r's output.
(See below)
% readelf -h bfd.ro
ELF Header:
...
Number of section headers: 0 (130574)
Section header string table index: 65535 (130573)
It's true that some tools don't support SHT_SYMTAB_SHNDX, and they are
broken tools.
For such an uncommon case (-r + linker script operating SHT_GROUP +
numerous sections),
it's true that broken tools exist, but it may not be used as an
argument, especially that ld.bfd -r output will confuse the broken
tools as well.
We can think of whether ld.lld output can improve in this case, i.e.
whether ld.lld should discard empty section groups.
I think it can be argued either way.
# Issue 2: relocation section non-compliance with the linker script
This is easily reproducible and others have provided examples in this thread. Here's a basic one:
$ cat b.h
#pragma once
struct A {
A();
virtual ~A();
virtual int foo();
};
struct B : public A {
int foo() override;
};
$ cat b.cc
#include "b.h"
A::A() {}
A::~A() {}
int A::foo() { return 42; }
int B::foo() { return 84; }
$ cat rela.sh
#!/bin/bash
clang -c b.cc
ld.lld -r -T ldscript.amd64 b.o -o rela.ro
$ ./rela.sh
$ readelf -SW rela.ro | egrep "RELA|PROGBITS"
[ 1] .rela.text RELA 0000000000000000 000040 000048 18 I 14 2 8
[ 2] .text1 PROGBITS 0000000000000000 000090 0000de 00 AXG 0 0 16
[ 4] .rela.text._ZN1BD2Ev RELA 0000000000000000 000180 000018 18 IG 14 2 8
[ 6] .rela.text._ZN1BD0Ev RELA 0000000000000000 0001a8 000030 18 IG 14 2 8
[ 7] .rodata PROGBITS 0000000000000000 0001d8 000088 00 A 0 0 8
[ 8] .rela.rodata RELA 0000000000000000 000260 000138 18 I 14 7 8
[ 9] .comment PROGBITS 0000000000000000 000398 000088 01 MS 0 0 1
[11] .rela.eh_frame RELA 0000000000000000 000518 0000a8 18 I 14 10 8
[13] .note.GNU-stack PROGBITS 0000000000000000 0005c7 000000 00 0 0 1
The .text1 directive of the linker script is followed, but the .rela.text directive is not. When a linker script is provided, my expectation is the linker will not be selective in enforcing the user's instructions. It seems to me this behavior only occurs with RELA sections, but maybe I have missed other cases.
Beyond that basic premise, this causes the same section count problem mentioned above at scale. This also leads to confusion because the rela.text._Z* sections above are named for a section that doesn't exist in the output.
In such a relocatable link, GNU ld appears to just skip SHF_GROUP
sections when matching input sections.
Arguably it is a dubious behavior as well, but it can avoid a problem
using section groups.
It doesn't need to discard empty section groups (your "Issue 1").
The generic ABI says "A section cannot be a member of more than one group."
When SHF_GROUP .text.* are combined, it's unclear how their .group
sections should behave.
# Potential Solutions
As I mentioned earlier:
1. Linker script syntax to exclude SHT_GROUP (solves Issue 1)
To discard all SHT_GROUP sections, you can use /DISCARD/ : { *(.group) }
There is no way discarding a selective subset of .group sections.
2. Linker script compliance for relocatable objects (solves Issue 2)
To not match SHF_GROUP sections in an input section description, I
think explicit syntax is better than GNU ld's current implicit -r
behavior.
This perhaps needs a Binutils discussion.
This is complicated by the fact that the behavior between -r and
--emit-relocs isn't super clear. In GNU ld, --emit-relocs input
sections are not matched.
3. "--relocatable-final" flag that instructs the linker to discard and combine sections as it does in other cases, e.g. shared objects (solves Issues 1 and 2)
I'd be concerned of adding a linker option.
First, I think there is something which should be discussed with Binutils.
Second, I suspect there may be some soundness issues which cannot be
perfectly handled.
I'd recommend that you migrate away from relying on certain .group or
.rela.* behavior in -r mode.
