The ability to set a custom label is still there, it just moved into System Settings. Click on the empty space in the Label column of the keyboard layouts table.

So this bug report is just about the ability ti display the label on top of the flag. It's easy enough to re-add, but I believe this was removed on purpose. Any specific reason you want it back? What's your use case for it?

(In reply to Nate Graham from comment #1)
> The ability to set a custom label is still there, it just moved into System
> Settings

Label doesn't mean only plaintext but its entire area including all other text/graphics (see typical labels in clothes, on food packages, etc.).

> Any specific reason you want it back?

Already stated can be re-added (bug 444864) after new report.  Only flags are quickly-noticeable but, due to dialects, useless/hindrance on their own; black on grey (or dark themes maybe unreadable black on dark grey) isn't noticeable, so without both (or everything custom for dialects) it takes longer before users notice/recall which layout is set.  It's comically absurd to create things users use and then remove them and then ask use case (happening since KDE3's end and indicates critical problems in a project).

(In reply to David Chmelik from comment #2)
> Label doesn't mean only plaintext but its entire area including all other
> text/graphics (see typical labels in clothes, on food packages, etc.).
Let's not misuse the term. Label is always text-only here (but you could try to put unicode symbols there).
So you are rather talking about label on flag feature, IIRC.

> > Any specific reason you want it back?
> 
> Already stated can be re-added (bug 444864) after new report.  Only flags
> are quickly-noticeable but, due to dialects, useless/hindrance on their own;
> black on grey (or dark themes maybe unreadable black on dark grey) isn't
> noticeable, so without both (or everything custom for dialects) it takes
> longer before users notice/recall which layout is set.  It's comically
> absurd to create things users use and then remove them and then ask use case
> (happening since KDE3's end and indicates critical problems in a project).
The label should be always noticeable in the first place.
If it's not, please report separately about this and add the bug to "See Also" field above.
  
(In reply to Nate Graham from comment #1)
> So this bug report is just about the ability ti display the label on top of
> the flag. It's easy enough to re-add, but I believe this was removed on
> purpose. Any specific reason you want it back? What's your use case for it?
At the time I designed it, it wasn't easy for me to re-add this in QML from the very first version, as there were much more important problems with the new applet needed to solve. So decision was made to put bare minimum functionality there and then the add more step by step. I have never had a chance to return to implementing this feature since then.

One thing to note:
text on flag was hardly distinguishable even on old applet.
There should be really smart reasons to re-add this, I would rather solve not noticeable label if that's the problem.

As a quick hack, you should be able to change Label text color in the applet's QML code, and tell us if it works for you.

(In reply to Andrey from comment #3)
> Let's not misuse the term. Label is always text-only here [...]

'Keyboard layout indicator: configure: configure: label' column is both text & flag!

> (but you could try to put unicode symbols there).

That'd be excellent/best if works in future (doesn't yet because flags are newer unicode/emojis that paste in wrong).
 
(In reply to Andrey from comment #4)
> text on flag was hardly distinguishable even on old applet.

It always was very distinguishable for me (may depend on flag).

> There should be really smart reasons to re-add this, I would rather solve
> not noticeable label if that's the problem.

For flags, customization is necessary because of dialects; we (me and users whose PCs I administer) use British Isles (multiple) & USA English (with international layouts only for dialects elsewhere) so flags alone are worse than useless: dialect can only be indicated by retaining text on flag or (another idea) changing flag.  Same for French, German, Portugese, Russian, Spanish (multiple dialects/languages in countries I'm unsure even label over one type of flag is enough).
        Dark Oxygen & dark Breeze lately had few/no system tray icon noticeability problems but can't check others until I have indicator for my layouts (disappeared, reported) or users whose PC I administer use dark themes (unlikely ever)... other themes would be their own issue, anyway.

(In reply to David Chmelik from comment #6)
> (In reply to Andrey from comment #3)
> > Let's not misuse the term. Label is always text-only here [...]
> 
> 'Keyboard layout indicator: configure: configure: label' column is both text
> & flag!
That's just ugly Keyboard KCM UI implementation right now which has nothing to do with the applet.
"Label" is only a text in this context so wrong Summary.

> 
> > (but you could try to put unicode symbols there).
> 
> That'd be excellent/best if works in future (doesn't yet because flags are
> newer unicode/emojis that paste in wrong).
Might be just pasting problem. I recall I managed to put Emojis in Label text field and it worked.
There might be also just Emojis package missing in system.

> > There should be really smart reasons to re-add this, I would rather solve
> > not noticeable label if that's the problem.
> 
> Dark Oxygen & dark Breeze lately had few/no system tray icon
> noticeability problems 
So no problem for Dark Oxygen & dark Breeze then?

> but can't check others until I have indicator for my
> layouts (disappeared, reported)
bug number?

(In reply to Andrey from comment #7)
> "Label" is only a text in this context so wrong Summary.
It started by saying 'Keyboard layout indicator'; isn't that the main graphical/text area--icon?  'Icon' doesn't imply (nor exclude) text.  I'll say 'keyboard layout indicator'.
 
> Might be just pasting problem. I recall I managed to put Emojis in Label
> text field and it worked.
It was Wayland (I consider under development/experiment/testing) KDE Neon but I could (after bug 456391) try X (preferable/stabler).

> There might be also just Emojis package missing in system.
On KDE Neon?!
 
> So no problem for Dark Oxygen & dark Breeze then?
I think (99%) were fine earlier 2022 but don't use them on my PC anymore (except icons, GTK) and unlikely family PC will use them.  Maybe later I can double-check.

> > but can't check others until I have indicator for my
> > layouts (disappeared, reported)
> bug number?
Bug 456391 (being worked on weeks/months by some people, which for my PC is more important, and for family PC clearly-indicated layout is more important, but they have more important usage (international/family documents/correspondence, not just getting single-quotation marks, pound monetary sign, attempting French & Germanic & Slavic languages, and editing Greek mythology texts (my usage))).

*** This bug has been marked as a duplicate of bug 444864 ***

You can try to directly put unicode text to label by opening ~/.config/kxkbrc in your favorite text editor.
DisplayNames is the line of interest, note a comma in the end if only the first layout of the two covered:
[Layout]
DisplayNames=abc,
LayoutList=us,ru

Best way to edit is just put something in Label UI of Keyboard KCM and then try to edit the file directly.

(In reply to Andrey from comment #10)
> You can try to directly put unicode text to label by opening
> ~/.config/kxkbrc in your favorite text editor.

Works but would sound too involved/difficult for many/most users.

(In reply to David Chmelik from comment #11)
> (In reply to Andrey from comment #10)
> > You can try to directly put unicode text to label by opening
> > ~/.config/kxkbrc in your favorite text editor.
> 
> Works but would sound too involved/difficult for many/most users.

As you tried it, were there any benefit in direct kxkbrc editing instead of putting the text in the KCM UI?

In reply to Andrey from comment #12)
> As you tried it, were there any benefit in direct kxkbrc editing instead of
> putting the text in the KCM UI?

Text configuration has it's place for theoretical computer science specific practical implementations in computer hardware/firmware/driver/OS & programming languages design/engineering & usage, command-line/shells, and all should be available to power users but unnecessary, and past necessity in GNOME/MATE is why I won't ever even consider those X desktop environments (DE) even though no longer require, so I can't say there's ever any GUI text configuration benefit other than should always be an option for every option/aspect/detail, but I'd rather not need

I won't mind having to (re)set/hack this for long/indefinite time in a file in family PCs and--when can try KDE again--my own PC, but more urgent/critical bugs prevent me from retrying KDE on mine (as much I'd like to, gave up earlier Summer 2022.)