`cd` does not travel to an "absolute path". It changes the working directory for the specified drive. Your prompt will still show you the old path (at A:), because you've not changed the folder for the current working drive, which yes, is kind of an insane concept.
If you want to actually change the working directory and drive at the same time (which is the "absolute path" idea you have), you do `cd /d D:\whatever\`.
Yeah I understood how it actually works, I'm just saying it's a potential huge footgun for someone writing a script coming from unix derivates.
At least if I had to write one, I saw cd is available and seemingly working as expected, and wrote a cd to an arbitrary target I would not expect it to behave that way at all - my expectation would be that either the next command always runs in the cd'd path, or at least that cd errors on a path in a different drive.
It was certainly weird for me coming from RISC OS. In that case, even though each drive has its own namespace (like with DOS/Windows), there's not just one "current directory" per session - there is in fact only one "current directory" per drive over the entire OS! As such, changing the current directory in one place would affect all relative path accesses using that drive, even in other programs.
It was common practice when writing RISC OS programs (and recommended by Acorn) to store your application's directory path into a system variable, and then use that to refer to all the ancillary files you needed.
I get the foot gun concern. But it's true going the other direction too.
Whether or not the gun fires comes down to what you're most accustomed to