> It will first try to mount the root parameter, after failing it'll drop you to a rescue shell. After mounting your root partition and typing exit, it will try again to mount the root parameter and only by exiting again the rescue shell it'll mount the correct partition and continue boot.
Your analysis is incorrect. You land in the rescue shell initially because $root can't be found. No attempt has been made to mount the filesystem.

Because of the way processes work, you have no ability to update the value of "root" in the parent process of the rescue shell (PID 1 at the time). I'm not really sure what you're expecting. This sounds like a pretty clear case of garbage in, garbage out.

Well, after getting in the rescue shell the first thing I do is mounting the root partition to new_root and then I exit it.
Only on situation d, after exiting, it will switch_root to the new_root partition; on all other situations it'll again try to use the $root value and I'll have to exit a second time before it switch_root to the new_root partiton.

Why not fix your kernel command line?

The kernel command line is actually fine, I am just testing how good is the recovery using base instead of systemd.
Once I accidentally done situation c with systemd on my initram and it didn't had any functional rescue mode to fix it, and I also didn't think about looking at the bootloader at the time.

I also didn't read the entire init file, only the relevant part about switching root to /new_root.
Can you explain me then if using $root again instead of switching root to /new_root is intended behavior, limitation or bug? And also why situation d is different from the others?

> Can you explain me then if using $root again instead of switching root to /new_root is intended behavior, limitation or bug?
Not really sure what you're asking. You can't substitute a device ($root) for a mount point (/new_root) in most scenarios, especially those pertinent to early userspace.

> And also why situation d is different from the others?
'c' and 'd' are identical scenarios. 'b' is special because it's a /dev path which can be waited on to show up (assuming udev is present). 'a' probably has strange behavior because /init expects that root is set.

Well, udev is on my initram as I said on the description.

Also I found another root parameter for testing:

e. Set root to anything that is not a partition and also is not "abc"

Using e you will get what you wrote on $root on the error message. Using d would make the rescue shell show "/dev/root" and also it probably skips one of the tests used on the init file.

Let me try again to explain what happens and what I think is the issue:

Let's say I booted with any of the five options.
IT would load fine until it needs the root partition.
If it was b init would wait 10 seconds for the partiton before the error happens.
For any of them I will get a error saying what it couldn't find/mount
If it was a it will show what it tried to use as ''. If it was d it will show '/dev/root'. If it any other option it will show the $root value.
At this point I get to a rescue shell
Here I mount my btrfs root partition to /new_root using "mount /dev/sda4 /new_root"
Then I use 'exit' and expect the boot process to go as usual
If it was d the boot process will go as usual (possibly this abc option somehow skips one of the tests). If it was anything else you will g
t another error.
This error says it's trying again to use the $root value and then you'll be back to a rescue shell.
I use exit on this rescue shell.
Boot will go as normal for all the other options.

The issue is that second error. I have already given it the right value (/init uses the /new_root mount point when it runs switch_root), why is it not trying to use it instead of trying the same value that didn't work? And why does it leave to only try the mount point I set when, if I otherwise didn't mount it, it would cause kernel panic?

This is becoming unintelligible. If you read /init (it's braindead simple), you'd plainly see that there's no check to see if /new_root is already a mountpoint before mounting the root device. I contend that adding this would be a waste because in 99.9% of scenarios, it's useless.