@ThomasBW84 With the way 3DShomebrew is currently set up, if you ever have the chance to downgrade/upgrade to 9.0-9.2, you can always run Custom Firmware as this is where homebrew has full control exploits on the 3DS.

With full control, we can make backups of our entire system. We'll call our 9.2 system sysNAND for simplicity. A 9.2 sysNAND can run a Custom Firmware that boots a copy of your system (via the backups we can make) that is updated to the latest system version. This copy is called emuNAND or redNAND, depending on how the memory is stored on the SD card. Using this method, it is true that the 9.2 syNAND isn't touched, because updating your sysNAND from 9.2 would make you lose the ability to run Custom Firmware. But with this method, you can update, play online, and do whatever you want on your updated emuNAND or redNAND because the Custom Firmware patches out certain things, such as signature checks and exploit patches in updates such as 11.0. Overall, this method is called Menuhax, as to boot your emuNAND or redNAND instead of your sysNAND, you can use a homebrew exploit that was patched in 10.6 (but still works on 9.2) that loads a homebrew executable on boot. Using a boot manager exeutable instead of the homebrew launcher executable allows people using this method to boot their system with Menuhax and automatically boot into their redNAND or emuNAND, so the old 9.2 sysNAND is completely bypassed and is only useful for a few other things that require full control, such as making system backups.

There is even a method to run Custom Firmware using the OTP (one time programmable) key unique to each 3DS that allows your sysNAND (instead of an emuNAND or redNAND) to have Custom Firmware access, even if it is updated. This method is called Arm9LoaderHax, commonly abbreviated to A9LH. With this method, people first back up their 9.2 sysNAND. Then, they create an emuNAND or redNAND if they haven't already. From there, in order to dump the console unique OTP, you need to downgrade the system temporarily to 2.1, as since 3.0, the OTP has been locked in the bootrom, but before 3.0, it was stored in userland (essentially what the homebrew launcher has access to). Since this system version is very old (the 3rd ever update created for the 3DS), none of the Custom Firmware programs support running an emu/redNAND on 2.1. So, we downgrade our emuNAND or redNAND to 2.1, but since no Custom Firmware supports running a 2.1 emuNAND or redNAND, our emu/redNAND will appear "bricked" by the downgrade. However, if we make a backup of this 2.1 downgraded emu/redNAND and flash it (copy over) to our sysNAND, our sysNAND will be able to run 2.1 just fine. From there, we use a browser exploit to gain userland control and dump the OTP file itself. We can then use the same program we used to dump the OTP to restore our 9.2 sysNAND backup.

From here, all that is necessary is to install the exploit itself. This is done through running an application in the Homebrew Launcher on a 9.2 sysNAND where the OTP dump is required as input. This exploit essentially writes unique (due to the OTP being required) "junk" data to our sysNAND so that as a result, it will always jump to a payload that can run Custom Firmware or even applications that require full control, such as the system and emu/redNAND backup program or decryption programs milliseconds into the boot processs while not having full control firmware (a.k.a. 9.2). Once the exploit is installed, you can use a Custom Firmware to run and patch your sysNAND instead of your emu/redNAND like in the Menuhax method. One of these essential patches blocks updates to the NATIVE_FIRM partition of your sysNAND. You know what this partition stores? All of the exploit patches, from the 11.0 minimum title list to the 10.6 browserhax/menuhax patches. This partition is also where the Arm9LoaderHax exploit is installed. So essentially, with this partition being blocked from updates, I can update my sysNAND running on Custom Firmware while still keeping full control of my system on current firmware (11.0).

Essentially, I think the best comparison to make if this is hard to understand is that 3DS homebrew is like a stock fund. Let's say that the stock fund represents full control hacks on the 3DS. There are "shareholders" that have already invested in this fund by downgrading their sysNAND to 9.2 at some point in the past to either run the Menuhax method or the A9LH (Arm9LoaderHax) method of homebrew. Those people will always have the ability to keep their share of the fund (keep full control hacks) if they wish. However, there is a couple more groups involved in this comparison, and one is the people on 4.X-8.X and 9.3-10.7 that could be a part of this fund but have not because they have not up/downgraded to 9.2 yet. These people can be a part of the "full 3DS control" fund if they choose to down/upgrade to 9.2. Then there is the last group in this comparison, the people on 11.0 (without using Arm9LoaderHax, obviously) who cannot join the fund (downgrade to 9.2) without getting a hardmod. And since the majority of 3DS users (I would say) are not willing to get a hardmod for their 3DS, for the most part, this stock fund of "full control on the 3DS" is closed for most of these new would-be investors.

In short, the people who have a 9.2 sysNAND with an updated emuNAND or redNAND (the Menuhax method) or the people who got to 9.2 at some point in the past and installed Arm9LoaderHax instead will always have the ability to keep Custom Firmware with full online access (with Menuhax, the emu/redNAND has full online access and update capability, the 9.2 sysNAND does not). But as getting to 9.2 at some point is required to install Custom Firmware in any situation, if Nintendo can block that initial downgrade to 9.2 for new users (as they did with 11.0 already), they can plateau the number of people with permanent full control Custom Firmware to the people who did it in the past, essentially closing full control *hax to new users. While some users on 11.0 will have access to the Homebrew Launcher through Freakyhax or the other games that have been taken down from the eShop, it doesn't matter anyway on 11.0 because downgrading through the Homebrew Launcher is only possible on 10.4 NATIVE_FIRM or lower (e.g. 4.X-10.7), so without a hardmod to downgrade NATIVE_FIRM from 11.0 to the one used on 10.4-10.7, 11.0 users cannot downgrade at all.

The new 11.0 exploits are truly only for Homebrew Launcher access. If 11.1 came out or something that patched all the 11.0 exploits people without Custom Firmware would have to stay offline (not update) to keep Homebrew Launcher access. I even did this for a period of time when I stayed on 10.5 for a while because 10.6 patched Menuhax and I was too cheap to buy Ocarina of Time 3D, which worked on 10.6 (As soon as the 10.4-10.7 downgrade exploit came out though, I downgraded to 9.2 and installed Arm9LoaderHax, so now my sysNAND is 11.0 but I still have full control and Custom Firmware like a 9.2 system does). However, this behavior of keeping a system offline does not happen when we're talking about anybody with Custom Firmware, because with Custom Firmware, any exploit that was patched can be patched back in by the Custom Firmware program itself. So, with 11.0, you know how Cubic Ninja was patched out? Well, due to the fact that my Custom Firmware reverted this patch, I can still use Cubic Ninja on 11.0 using my Custom Firmware sysNAND, even though other non hacked people on 11.0 could not do so.