How does it start and configure then?
There is a BIOS ROM.
Its job is to run the !Boot application.
!Boot always resides in the core if the FS.
BIOS also has basic flash/network/cdrom/floppy driver.
So if you damaged your !Boot, you can easily recover.
On simpler installation, without an external kernel, !Boot can be just a script or an executable, instead of a proper app.
Now the root !Boot folder has another !Boot (can be an app or a script). That !Boot loads all drivers, starts desktop and does user login. The root boot also has !Run, which runs when the user clicks the root !Boot to configure OS (akin to Windows control panel, but a bit smarter and much more flexible).
Each application also has its own !Boot, which can optionally be `seen` by the root !Boot, which registers all services and kernel modules associated with that application. That is how file associations and file icons gets registered, without cluttering the registry. Applications are also `seen` when the user enters their folder. Same way, newly connected devices designed to work with RISC OS can `hard-load` the application necessary to work with them. For example, GPU used to install its driver, so user wont have to do the installation.
Major variables, like boot method, are saved to CMOS, and everything else gets saved under !Boot, inside config files, which user isn't supposed to edit (compared to Linux with its /etc). If some service needs startup configuration, it should install its configuration app under !Boot.
File type can also have several apps associated with it, it all depends on which app is currently `seen` or `booted`.
It also has a few funny convention on how to switch association, without changing file name. For example to debug existing executable, you change its type to DebImage, which passes it to a debugger. That is nice since it doesn't change the name of the executable, which is a thing many Unix programs depends upon (i.e. grep could behave differently depending on its symlink name) and you don't need to start a debugger separately (like I do currently with GDB).
That is just one step before a semantic filesystem, or database filesystem, where each file can have multiple type tags or faces, depending on how it is used. These semantic filesystems are very good for modern LLM driven AIs, since they can easily look through thousands of files, as long as they are tagged properly.
