getPermission does not convert plugin label to string properly

The label should never be a string but always an instance of TranslatableMarkup. Sounds like a bug in the ggroup patch. See GroupNodeDeriver for an example in case the bug is in a deriver.

While I agree the label should be TranslatableMarkup, the GroupContentEnablerInterface::getLabel() currently @returns a string. Since the patch results in an identical implementation but without the backwards compatibility break, it is superior to the current code in HEAD.

On a related note: using magic methods on classed objects to use as array keys is not a very robust way to generate sections, but Iet's discuss that in another issue.

While I agree the label should be TranslatableMarkup, the GroupContentEnablerInterface::getLabel() currently @returns a string. Since the patch results in an identical implementation but without the backwards compatibility break, it is superior to the current code in HEAD.

Core is full of examples where an @return mentions "string" but it actually returns translatable markup. I frown upon this myself, but I guess the intention was to say "You may treat this as a string".

I'd rather update the erroneous docblock to mention the true return value than adjust the return value. If people currently have code that calls $returned_label->getArguments() for instance, it would now crash. So changing it to always cast the return value as a string, could be regarded as a BC break.

Updated the ggroup patch to fix this (see #2736233-149: Port Subgroup (ggroup) to the D8 version). Also attached a patch to fix the docs, as well as a patch to make getLabel() a bit more flexible. I think I prefer to keep the docs an make sure the methods actually return a string, but I guess it's up to you to make the final call on this.

#7 The 2933819-7-docchange.patch would make sense, but in 2933819-7-superflex.patch you return a string instead. Are these alternative approaches to fix the problem at hand? I fail to see the logic :(

Yes, these are alternative approaches. One changes the documentation to match the implementation and the other changes the implementation to match the docs.

The plugins returning a string for a label were failing (this changed somewhere between rc1 and rc2), even though the docs are saying a string is what should be provided. I'm not sure if we should really change the API from a string to FormattableMarkup/TranslatableMarkup when we could easily accept both and not break anything. Besides that, almost all implementations of getLabel() in Core return a string instead of FormattableMarkup/TranslatableMarkup, so that's another reason why I slightly prefer returning a string.

Closed #2973005: Fatal error on permissions page - call to __toString() on a string. as a duplicate issue.

There is no need to call $thing->__toString() on those objects. The same thing is to do (string) $thing. I'd prefer that. I agree with the reasoning in #10. Let's return strings.

Drupal core has updated the variable type to string|\Drupal\Core\StringTranslation\TranslatableMarkup, see #2921307: \Drupal\Core\Entity\EntityTypeInterface label methods docblocks should be to return TranslatableMarkup

Ideally this issue should apply the pattern in Drupal core.

Following core is (almost) always the right thing to do, agreed.

Used suggestion from #14.