confused by the ropi specification

"Luckily, technical English appears to be the easier subset of the language :-)"

I'm pretty sure there are a huge number of native english speakers who do not agree on that :)

Anyway - consider the PC.

MS-DOS didn't have multitasking.

Windows have multitasking. But the applications do not own interrupt handlers - they are owned by the operating system as shared resources for the applications to alocate and use. It gets interesting when you have two completely different embedded applications that wants to interface with the hardware and install interrupt handlers. There is only one interrupt controller.

Multitasking two embedded applications is harder than multitasking two desktop applications.

Another thing here is that if you relocate an application, you can have it running at a different address. But how will you know what RAM memory ranges it needs? Because the second application must not use the same RAM regions. Having relocation entries for all RAM accesses isn't enough to be able to also know how much RAM that is used. Next thing is that the ARM instruction set often don't allow arbitrary accesses unless all accesses are made relative to an index pointer. In many situations, registers are loaded with constants of limited width with an optional shift. And same with memory accesses - offsets or absolute addresses are compressed to a limited width with an optional shift. So you can't get away with a relocation table that updates 32-bit memory values with an extra offset. So you may need to have the compiler produce accesses relative to a common pointer.

In short - the number of problems to handle tends to add up, making some projects cost much more than the expected gain. Settling for just two applications at a time, and linking every application twice - one "low" and one "high" link - is a way easier way of writing code that can load two-of-n applications and then have them multitask concurrently.

"Luckily, technical English appears to be the easier subset of the language :-)"

I'm pretty sure there are a huge number of native english speakers who do not agree on that :)

Anyway - consider the PC.

MS-DOS didn't have multitasking.

Windows have multitasking. But the applications do not own interrupt handlers - they are owned by the operating system as shared resources for the applications to alocate and use. It gets interesting when you have two completely different embedded applications that wants to interface with the hardware and install interrupt handlers. There is only one interrupt controller.

Multitasking two embedded applications is harder than multitasking two desktop applications.

Another thing here is that if you relocate an application, you can have it running at a different address. But how will you know what RAM memory ranges it needs? Because the second application must not use the same RAM regions. Having relocation entries for all RAM accesses isn't enough to be able to also know how much RAM that is used. Next thing is that the ARM instruction set often don't allow arbitrary accesses unless all accesses are made relative to an index pointer. In many situations, registers are loaded with constants of limited width with an optional shift. And same with memory accesses - offsets or absolute addresses are compressed to a limited width with an optional shift. So you can't get away with a relocation table that updates 32-bit memory values with an extra offset. So you may need to have the compiler produce accesses relative to a common pointer.

In short - the number of problems to handle tends to add up, making some projects cost much more than the expected gain. Settling for just two applications at a time, and linking every application twice - one "low" and one "high" link - is a way easier way of writing code that can load two-of-n applications and then have them multitask concurrently.

the number of problems to handle tends to add up, making some projects cost much more than the expected gain

How do you compare the effort (cost) of building the aforementioned system with the gain of satisfying somebody's curiosity?
I think labour cost is a factor here. Once the OP starts making good money as an engineer (and I do hope he does), he'll be more careful with his time :-)