Bug 425476

(In reply to Roey Katz from comment #0)
> I'd love to set individual tabs to look like older terminal emulators like
> those from Cool Retro Term (https://github.com/Swordfish90/cool-retro-term).
> 
> 
> Linux/KDE Plasma: Kubuntu 20.04.1 LTS
> (available in About System)
> KDE Plasma Version:  5.18
> KDE Frameworks Version: KDE Frameworks 5.68.0
> Qt Version: Qt 5.12.8 (built against 5.12.8)

Some people want Terminal Multiplexers. It sounds, like what you would like is a Terminal Emulator Multiplexer. And I basically had that and more implemented by an old tiling WM, ion3 (that's now dead - thanks for the author, who had weird selfish motive to use non-FOSS source-available license. I'll come back to it later. Also, it was Ion2 when I started using it - no idea why the major version number was part of it's name. It wasn't like Links2 browser, that apparently was forked from Links, with distros usually providing both in their repos - except Fedora, which provides simply Links, which is actually Links v. 2.*, i.e. Links2.

Anyway, most Terminal Emulators today are in fact Terminal Multiplexers. There once was a time, when for example GNOME Terminal would run just single terminal emulator window - and there might have been a multiplexing version of it, which could run several terminal emulator instances in one process and in one window. You could have them in tabs, and you could split the window both ways, and as many times (i.e. you could split the window, then you could split either or both halves the same or opposite way. Like splitting horizontally. Then splitting the top one horizontally again, and splitting the bottom half in two, but this time vertically. So you would end with top half having two terminals on top of each other, and the bottom half having two terminals side by side.
Still existing example of non-multiplexing terminal is RXVT, and it's multiplexing counterpart, MRXVT. Though it only supports terminal tabs, it's still as much a multiplexer, as ones that support splits.

There's also the "original" terminal multiplexer, one that existed when GUI terminal emulators that could run multiple terminals within one process were a rarity at best. Nowdays it supports both, "tabs", and splits, but the latter wasn't always there. Especially vertical splits came way later than horizontal splits. You might think that it's not a Terminal Emulator, but just a multiplexer, because it's actually terminal application itself. I'm of course talking about "screen". What, you thought it was tmux, LOL? Bah! No, the screen has to be a terminal emulator itself, and a very special one at it. It must be able to tell what a specific windows contents is like, even just to be able to switch between different windows, and having their content shown when switching back. And screen's VT100+ support can only support features it knows. Furthermore, the underlying terminal that screen outputs to, might not itself support all the features that screen does - but as long as it can move a cursor, and print the characters, screen can emulate it's features on any terminal. It can even use different charset than the terminal, and convert between them.
All this is also essential, because a screen session can be detached from one terminal, attached into another (especially if you're connecting remotely via ssh to another system where you keep a screen session running - you might have multiple devices, from an actual VT100 Terminal, to a DOS PC running a program most commonly used to connect to BBS's via modem but work just as well with null-modem cable, or ConnectBot on Android).

This is why I usually don't ever even use the GUI Terminal Emulators tabbing nor splitting features. Instead, I simply run a screen session inside the terminal window - this doesn't have only benefits though, but most of the time I value the pros more. Like, if the terminal emulator crashes, you lose everything running inside it. Except in case of screen - sure, you lose one process, but your session is still running in a different process. The process running inside your terminal merely communicated with the process actually running your session, and you can reattach it after opening a new terminal.

BUT HERE'S HOW I MANAGED TO IMPLEMENT, WHAT YOU'RE LOOKING FOR, by utilizing a tiling WM.
Ion3 was available as source. But it's license didn't allow spreading of modified sources, nor binaries built from such. But the author actually supported another way for releasing modifications, and even offered to make them available on Ion's website (I will now refer it to as only Ion - and by it, I mean Ion, Ion2 and Ion3). That method was patches - and you had a right to apply patches, and create your own modifications, providing you didn't redistribute the resulting source code, nor any binaries built from said source.
Still, while Red Hat, and other distros, often weren't playing fast and loose with licences, and for example simply release new kernels, which ship with nVidia drivers as readily usable module, that has their binary blob inside. Yet, it seems that they were less concerned about licences of products from a lone developers - which also speaks volumes of Red Hats true attitude towards respecting licenses - nVidia, as well as Linux Foundation, could actually be a real threat to them, and they *would* both raise hell, if Red Hat were to break the terms.
What is it that I'm talking about? Well, the RPM package Red Hat provided Ion WM binaries from were patched - though I was glad that they did so, as I didn't feel like compiling them from source... I'm way more likely to do that nowdays - I just had to build screen from sources to get fullcolor support, because Fedoras repos still lag behind. They are still stuck at screen v. 4.x, and full colour support needs v. 5.x. Same deal with ELinks browser, that I needed to compile by hand already years ago for the same reason - but back then the distros didn't provide builds with 256-colour support. Now they do, but not with fullcolor support. And it's not that they are on too old version of ELinks, but just that they simply don't care enough to use configuration options for enabling it. But still they had taken the effort of actually applying some of the best patches available for Ion.

And one of them was a "scratchpad window". It enabled you to show/hide one floating frame over the tiling desktop. Ion did support floating windows, but only on separate virtual desktop. You could open a new virtual desktop, and it could be tiling or floating windows. But the "scratch window" showed that it could easily be made to support even multiple floating windows, that could be hidden/shown on top of the tiling mode.
But the interesting part. That wasn't actually a window - it was just an empty frame. But you could launch a new program window inside it. Just like with tiled frames. And in deed, despite of the frame being smaller than the one big frame you would get when launching Ion, it worked exactly the same. In Ion,, you could split the frames into two, then you could open applications, and their windows would become tabs in the active frame. You could do that with the "scratchpad" as well. You could open application windows, and they would become tabs inside the frame. And you could split that frame into parts.

So basically, by using the "scratchpad" to launch only terminal emulators inside it, you could open konsole windows, and you could open Cool Retro Term windows. Or any other that you wanted. And you could open and hide it with a keybinding of your choice. The only thing lacking is the "drop down animation" - otherwise it was just like drop-down terminal windows - but you weren't even limited to terminal emulators only.

It was a very cool idea. And at least something close to it should be doable with any modern tiling WM - unless it doesn't support making any application window into a floating one. Depending on the WM, you might be able to configure the window to have it's own keybinding to toggle it's visibility - many tiling WM's that support floating windows as well, only have a single binding to show/hide all floating application windows, but they might be capable of having a binding for specific window as well. Also, the floating window support of a WM would have to actually support floating frames - that could contain multiple windows. At least as tabs, but preferrably the floating frame should also support splits, like the scratchpad in Ion.

That's the only way I know how you might be able to implement anything like this. Unless you can make a GUI application that can swallow other windows to show them inside itself, this is the only method I know.
I'm willing to bet that Konsole devs don't want to try and implement another Terminal Emulator in the same code, nor will I believe that they would want to support swollowing other application windows inside their window - and I think such swallowing will only work, if the application you want to swallow implements support for it itself. If I'm wrong, and it is possible to just swallow windows without them having any say on it, then you could just program yourself a "Terminal Emulator Multiplexer" that swallows different Terminal windows to then show them as tabs - and maybe also inside split-frames. But AFAIK, the only existing solution I know for this, is the one implemented in Ion WM (patched with a "scratchpad" patch) - I don't know how well it can be  implemented in modern tiling WMs, even though they do support floating windows out of the box, unlike Ion did.

No I've rambled enough. Hopefully this actually helps, or even feeds someones interests, at least someone. I just thought that this idea of using WM features to implement the kind of feature that you're looking for.
Also, theres floating WM's that support window tabs as well - like BlackBox, and/or FluxBox. One or both supports tabbed windows - but I don't think they have means to hide show/hide the one specific tabbed window set with a key binding.