That’s a 40% price increase just to get your keyboard layout and a CPU upgrade

Fixed that for you*.

Unless you really want vim bindings

I kinda do for how ubiquitous Vim keybindings are.

try them out.

Regardless, I think I will try it out after I'm at least somewhat productive with Vim.

I much prefer the way Kakoune works over vim

I think preference is generally subjective. So you're completely in your right to prefer Kakoune over Vim (and vice versa). Though, if possible, would you mind elaborating what you prefer exactly and why?

while still being close enough so that you can pick it up quickly if you already know vim and the other way around.

Doesn't that disrupt muscle memory?

I have used vim/neovim for years and cannot go back to a non-modal editor. But TBH I got sick of its configuration. You need far too many plugins and config to get things into a sane working order to be usable on a day to day bases for any type of development. It takes ages to learn and become as productive as you were before and a lifetime to refine.

Interesting. Though I can definitely see where you're coming from. Uhmm.., have you used any of the Neovim distributions to make maintenance easier?

For the past year or so I have switched to helix and don’t plan on going back to vim/neovim as my main editor ever again.

Both Helix and Lapce have certainly piqued my interest as FOSS alternatives to VS Code. However, both have issues related to how well their current Vi(m) implementation is. As you've touched upon it; Helix' keybindings and 'sentence-structures' are different to those found on Vi(m).

Furthermore, neither of the two have existed long enough to be able to profess any statement regarding their longevity. Like, there's no guarantee that I can keep using either of the two 20 years into the future. While no program is able to 100% guarantee that, undoubtedly, the track records for both Emacs and Vi(m) testify that -if anything- they would be the most likely ones to survive 20 years down the line; like how they've done for the last couple of decades.

I appreciate the input, but I simply don't want to invest in a program whose future is very unclear to me at this point in time.

Thanks for answering! Much appreciated!

I might be a distro hopper. Every distro just niggles me after a while

Perhaps you've yet to find the one 😜. Your criticism to the different distros is fair though.

I thought Arch because it is almost always up to date and seems to be widely recommended.

Yup, it's by far the most popular rolling release distro. Though, I'd argue that openSUSE Tumleweed -while not as popular- is definitely worth checking out as well. They're, however, quite different from one another. Arch offers a blank canvas, while openSUSE Tumbleweed is relatively opinionated; though it does offer excellent defaults. You would have to make up your own mind whichever 'style' of maintaining a distro suits you best.

I had a go at installing Arch today in a VM using archinstall and set up BTRFS with Timeshift and grub-btrfs and it all seemed fairly straightforward.

Well, that sure does sound promising!

OP was relatively verbose so I act accordingly. Don't feel compelled to read larger pieces if you're sensitive to wasting your time. I don't recall forcing you to read it, so it's entirely on you. While information density might have suffered, "little info" is too harsh. Though, as long as there's even one sentence of 'original' information (compared to all the other comments) a piece of writing of that length is worth reading IMO. Though, thinking otherwise is definitely justifiable.

Surely dotfiles are meant to change over time?

Indeed. But any and all changes should await my 'permission' of sorts before being committed declaratively (or related) if at all. This might indeed make it hard(er) for software to create and change dotfiles as they will, which is somewhat the intended purpose.

DuckDuckGO for the bangs, with a custom !bang made for my favorite SearXNG instance; on which most of my 'googling' actually happens.

You can install Distrobox on Fedora (or any of the distros that support it), create a Debian distrobox on your Fedora install, and within the Debian distrobox you can use apt-get to install whichever Debian package you like. Or..., you could make an Arch distrobox and even install stuff from the AUR. Or really any package from any of your favorite distros as long as it's supported.

You can even install KDE on Mint, and configure it however you want.

Personally, I'd advice against this as KDE is not supported on Linux Mint. While this doesn't have to mean much, it does mean a lack of polish and sophistication you might expect on Kubuntu or Fedora's KDE Spin or openSUSE (on which KDE is the default DE). This might result in some edge-case bugs and other mishaps that might trample your experience; thus giving you the wrong idea about KDE. Instead; consider booting into a Live USB of any distro that comes with KDE by default.

So taking your other comment into consideration as well, I suppose the following would be the easiest good setup:

1. Install Debian Stable using the image for a minimal network install onto a secondary device or onto a partition of your main device (multi-boot). Make sure to only include the stuff you think you'd need.
2. Install all of your favorite tools within that Debian Stable installation.
3. Use the excellent penguins-eggs package to make a live image out of it.
4. Install the live image onto your favorite USB with whichever tool you like; personally I enjoy using ventoy.
5. Profit :P .

If my proposed solution doesn't quite fit your needs, then please feel free to correct me!

Would you be fine with some tooling that enables one to make their own custom iso from an existing distro? This path still allows for a substantial amount of freedom, though it's not a blank slate by any stretch of the imagination. But it makes up for it with how relatively easy and painless it can be.

Or would you instead like to get into the nitty-gritty of things and want all the freedom you'd want? This increased freedom does come with a substantial cost in convenience and labour.

Pick your poison :P . I'll be waiting ;) .

has anyone here used this who can comment on it?

I've been on uBlue since a couple of months. Initially, I just rebased to their silverblue-main image because it offered a more sane image to build upon as all of their images have already applied every relevant step everyone does to their 'Silverblue-systems' anyways; codecs, enabling hardware-acceleration, support for nvidia + secureboot when applicable etc. But recently I've started building my 'own' image using their toolkit and it has been a blast. I'm a huge fan of what NixOS and Guix do in the space of declarative distros. However, unfortunately, I had my reasons to not go down that route. The toolkit offered by uBlue enables me to have (pretty much) a declarative system on a more traditional -albeit 'immutable'- distro. If one desires reproducibility, atomic updates, very high security-standards and a pinch of declarativity to eliminate bitrot, configuration drift, unknown states etc; then one simply can't ignore uBlue's offerings as one of if not the best solution out there.

i see a lot of recommendations for nobara, but this seems to do a similar thing in a more convenient and reversible way

Nobara is great and does indeed have similar design goals; namely improving the stock experience. To put it bluntly; Nobara is to Fedora Workstation what uBlue (thus including Bazzite) is to Fedora Silverblue. To be clear; uBlue offers a fleet of different (base-)images; thus enabling everyone to use their favorite desktop environment on their 'Immutable' Desktop; even those beyond GNOME, KDE and Sway that Fedora itself supports on their 'Immutable Desktops'. So in that sense -perhaps paradoxically- Nobara is more rigid on install than uBlue, while the latter is the one referred to as 'immutable'. It's perhaps important to note that uBlue is not a distro; at least not in the traditional sense:

"This isn't a distribution, you can always rebase back to Fedora without reinstalling. This is a unique relationship between an upstream and downstream that is popular in cloud, but still new to the Linux desktop. "Custom images" seems to be a decent place to start since that's what people call them in cloud."