It should automatically switch to the next version, as the “testing” keyword gets passed down between versions. I’m not sure though

That is standard in all of Debian, just get it as a flatpack.

Yes, that's why I installed it from unstable. The ESR version is an older version with added security patches. I'm not sure, why exactly they are doing it like that and I don't think it's a good idea. I'd say a browser should be as up to date as possible for both, bug fixes AND new features. But it worked flawlessly using the "unstable" firefox package. Another option would be the flatpak, but that's not that well integrated into the system - last time I tried that, the font rendering in the browser was awkward. I use some other flatpaks though, most notably gimp and inkskape which work really well and are very up to date that way.

I have had a great experience with tumbleweed.

What you're proposing is creating a Frankendebian, which Debian explicitly warns against doing. The proper way of getting security patches from unstable would be to pull the source debs and compile it yourself against the current Debian testing base.

This lane of thinking however seems to be completely misguided when it comes to the target audience here, that is, a user who is not even experienced with Linux in general enough to know about various rolling release distros. Telling a user this inexperienced to go with either of those is in bad taste at the very least.

Yes, Devuan is more stable. It's not modified or forked, it's still Debian .deb files but with a different init system.

The difference is systemd is one thing to handle everything. The other inits are launched or initiated each time something thing starts on an individual basis.

I have heard that systemd has greatly improved, but a different init starts a new process ID for each separate program so if something locks or freezes, it affects that one inidividual init process. For systemd, which runs system wide to handle everything, if one program locks, systemd has to make adjusts for the whole system to fix the problem.

I also tried Artix, which is native Arch without systemd, and while it was still a rolling system like Arch, I found Artix to run smoother or lighter than Arch.

Some people find command line with systemd easier to do becase it is one centrslized control system, I say no, what you gain in ease of management you lose in optimal performance and precise control over each individual one, as opposed to systemd being a blanket system. I want Firefox running an isolated process from the one that Plasama desktop is running, each sith their own init started only when each one was started and not controlled by a shared resource.

Where can I track package versions without installing? https://packages.debian.org/trixie/ and https://packages.debian.org/unstable/ show outdated packages.

@tubbadu the problem are security updates, that get to testing later

Some points I handpicked for you. Ignore the uninformed masses.

The Debian GNU/Linux FAQ

Chapter 3 Choosing a Debian distribution

3.1 Which Debian distribution (stable/testing/unstable) is better for me?

If you are a desktop user with a lot of experience in the operating system and do not mind facing the odd bug now and then, or even full system breakage, use unstable. It has all the latest and greatest software, and bugs are usually fixed swiftly.

3.1.5 Could you tell me whether to install stable, testing or unstable?

Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.

Unstable has the latest software and changes a lot. Consequently, it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.

3.1.6 You are talking about testing being broken. What do you mean by that?

Sometimes, a package might not be installable through package management tools. Sometimes, a package might not be available at all, maybe it was (temporarily) removed due to bugs or unmet dependencies. Sometimes, a package installs but does not behave in the proper way. When these things happen, the distribution is said to be broken (at least for this package).

3.1.7 Why is it that testing could be broken for months? Won’t the fixes introduced in unstable flow directly down into testing?

The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let’s say this threshold is 5 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 5 days. The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps testing in a usable state for most of the time. Overall a brilliant concept, if you ask me. But things aren’t always that simple.

tldr: "The goal of the Debian project is to produce Stable". Sid is essentially a rolling release, it's nothing like Fedora Rawhide in the old days when was essentially a testbed for Red Hat but it's not meant to be as smooth as, let's say, Arch or Tumbleweed. Testing in the other hand isn't merely some layer between Unstable and Stable, it's part of a bigger project, Testing exists for the sake of Stable, not for the sake of Testing. Same logic applies to Unstable but you do achieve some level of "just works" when you're just pushing all the latest software, after all Debian also has Experimental but you should still expect breakage when something truly major happens.