if I was using a different language that is no longer compatible with POSIX or Bash, then why would I use Fish instead any other language? Why not Xonsh (Python) or Nushell in example?

I think this is a great question, and the answer is probably more nuanced and personal, even per use case.

I use fish because of its simplicity, period. And it had all the features I wanted from zsh built-in, with zero or simpler (actually understandable) configuration.

I don't help anyone with bash or write or share scripts, so I don't have that issue where I need to juggle multiple shells, which is lucky for me perhaps. 😌

But those other steps you mentioned probably are a bit more niche, let's say. I think nushell is more tailored to people using the shell to process a lot of data. Digging through logs, perhaps. Debugging systems, or systems management/maintenance. Then it's really handy to be able to process output as data tables, with proper sorting capabilities etc. Nushell is really powerful for that. I actually have it installed because it's already useful sometimes but I barely know any of its specific commands. 😅

Anyway, the choice of shell really is very personal. For me, fish and bash share the same purpose of being used both interactively and as general-purpose scripting languages. And since fish is better in my opinion I chose it. But if I had other use cases, maybe a different job with different requirements, I would make nushell my default. 😁

The protocols designed for Kitty are great, but I when I last gave Kitty itself a try, I felt it was extremely opinionated in a very off-putting way.

It was advertised as being highly extensible and scriptable, but despite that, I found it to be less flexible than my old setup which wired up tmux with Python scripts. For instance, I was able to track which pane was previously active when creating a new split, allowing me to have the newly-created pane's bashrc read the old pane's bash /proc/ entry to copy the environment variables. That wasn't possible in Kitty. And although Kitty's splits layout were functional, resizing the splits themselves was an unconfigurable pain in the ass because the sizing is based on width/height rather than bounding boxes.

I would normally chalk that up to growing pains of a new project, but reading through the GitHub issues and documentation didn't leave me with the impression that the author cared about how something could be done in Kitty, but only that it could be done in the most basic sense. If the user's workflow would benefit from having a partial overlay or popup, tough shit—they can either use a full overlay or create a layout for it.

It didn't sit well with me, and moving to Kitty full time would have been a downgrade in productivity for practically no real benefit.