The conflict between what you say about the bootloader being in ROM and it being in the MBR is perhaps due to bootloader being used for any code that works out how to do the minimum to load in code to make the computer do something useful, including each state in a multi-stage boot.
So, the starting state is to have a computer, which is a programmable device, but doesn't know how to load software to run because it doesn't have any software loaded. (And hence boot from pull itself up from its bootstraps).
Historically, there were a few different solutions to this problem, but these days we start with some code in ROM (mostly likely strictly EEPROM), which is enough to get it to look at different devices and try them in turn until it finds one that's bootable.
(This is why many systems will boot off a CD or DVD if you put an OS installer disk in and from the hard-drive otherwise, the BIOS [the code on the ROM, including the code we're talking about and some other low-level stuff that get things started] is set to look at the CD/DVD drive first, then at a hard-drive if it doesn't find anything, tweakers often set it to ignore the CD/DVD drive unless manually requested so it doesn't waste time spinning up a non-bootable disk that was left in the drive).
This code in the ROM is sometimes called a bootloader.
When it knows what drive to look at, it will then look at the MBR, which contains information about primary partions - how could you later look at / or /boot or C:/ (on a Windows system) if you didn't even know what part of the disk was which partition, never mind how each partition was mounted? - and some code with further instructions to execute. (Incidentally, this explains why some OSes - like Windows - can only be installed on a primary partition, the details of those partitions are in the MBR and that's the only partition information their bootloader has read, and it doesn't load the EBR to learn about the logical partitions, as far as it's concerned those partitions don't even exist yet).
That executable code, is also called a bootloader. When we care to distinguish between this and what comes next, it's called a primary boot loader (because unless we're making our own BIOS we ignore the ROM bit as out of our control).
That code will be very small as there's only around 400 bytes for it to fit in, so to do anything real, it will load some more code, that can be larger as it doesn't have to deal with this constraint.
This code, is also known as a bootloader. When we care to distinguish between this and what came before, it's called a secondary boot loader.
That code could perhaps be the final stage in the process. It would if you've only one OS, or if all the OSs on your system use compatible boot-loaders (e.g. two Linux installs that both use GRUB, so whichever GRUB was updated last can offer to boot into either of them) then it presents menus (if desired) loads in a kernel, and passes control over the the operating system.
In the case where you've an OS that isn't compatible with that bootloader, it may chainload. E.g. if you have Windows and Linux on the same machine, the GRUB option for loading Windows will in fact load yet another bootloader that only knows about the Windows installation(s), and pass over to it. While this was a tertiary stage in the process, it's still called a secondary boot loader, because it neither knows nor cares that there was another secondary boot loader running before it. This would also be the case with a Linux install that used a different type of secondary bootloader.
Mostly when we talk about the bootloader in terms of Linux, we generally don't mean the ROM code (it's not part of Linux, or changed by installing Linux). When we do
update-grub we're changing the secondary bootloader, which is typically in /boot of a particular installation. When we do
install-grub we're changing it and also the primary bootloader in the MBR so that it has enough code to know where /boot is (perhaps starting a software RAID as it goes) and will load and execute that when it, itself is executed.
So, in summary you were incorrect when you said ROM was part of main memory* because it's separate. (Indeed, RAM is taken as antonymous to ROM). You were correct both in saying there was a bootloader there and in the MBR, because they're two steps of the process and both are sometimes called by that name. And the answer to "Do different OS store their bootloader in different places?" is "mostly", because if you incompatible secondary bootloaders will either hide other bootloaders (if you install Windows after installing Linux) or chainload into the other one if requested (if you fix that situation, or install Linux after Windows), but an OS can share a secondary bootloader if they are compatible (if you install Linux after another Linux that uses the same type of secondary boot loader, and it can see the other Linux [sometimes software RAID confuses things and makes chainloading necessary).
*In days where one would programatically make use of both ROM and RAM this was different. On a ZX Spectrum for example, the ROM would be 16kiB and include a BASIC interpreter, so as well as giving you the starting point for loading something into its 48kiB or 128KiB (paged) or RAM, (in which case, it's essentially booting into that BASIC interpreter and then using that to boot into what was on the tape), there was a whole bunch of functions from the BASIC interpreter that programs in RAM could use (why write a trig function when the computer already has one at a known position? especially when you've only 48kiB for all your own code to run in). This ROM was also visible in the same way as the RAM, just at different addresses. In such a case the ROM was as much a part of main memory as the RAM, but not writable. These days you pretty much ignore the ROM once you're past the first stage of booting.