Greetins!

I am a newbie to MT and ROS so am learning the MT ecosystem. I have started my learning journey with an RB5009 with ROS 7.8. Since the default configuration of the RB5009 just works out of the box, I decided to use this as the basis for learning ROS by modifying it to meet the requirements of my LAN configuration. Reading the documentation, both MT and third-party, and also from this MT video, https://www.youtube.com/watch?v=jBC7mScNUjw, I concluded that I could export the router configuration with the export command, make incremental changes, then import the new configuration and see how much I broke. Alas, this does not seem to work as documented. When I import the configuration it immediately fails with a naming conflict. Running import in the verbose mode reveals that the script is failing on the first command which is defining the bridge.
It appears the imported script will simply not overwrite the existing configuration which does not make any sense given that is the purpose. No idea how to make this work, any help appreciated.

TIA!

Your conslusion is wrong. Video says: "Moving configuration"

Import just executes commands so it does not "remove + insert" or "update" but "add" each executed line to configuration.
It works only with "no default configuration" but you have to obey some rules during import.
Start there: viewtopic.php?p=984471&hilit=restore+co ... on#p984471

Okay, so import will not overwrite existing configuration. So let's try from a blank configuration. First do a verbose export of the router configuration,
Next, remove the default configuration,
Now the router has no configuration, so import the exported configuration,
import fails to load the exported configuration on the same router. Since I have a second RB5009, I remove the default configuration on the second router and import the exported configuration from the first router. Importing to the second router fails at the same point as the first router.

My understanding of import/export is that it permits saving/restoring of router configuration via a text script or exchanging configuration between possibly different model routers with possible modification depending on the target router.
Seems I completely misunderstand the purpose of export/import.

Using verbose does include absolutely everything, which may generate conflicts - to see what a 'blank' configuration actually looks like try it on a Mikrotik after performing a /system reset-configuration no-defaults=yes ...

If you use /export show-sensitive instead this only includes anything differing from the 'blank' configuration. Historically there have been various firmware versions where an export cannot be imported without editing it first, if you come across an example of this it is recommended to open a support case so the issue can be fixed.

Personally, I am still trying to figure out the bulletproof way to clone the configuration. Export with "show-sensetive" does seem to export the complete configuration (without the users, of course, but at least the wireguard peers are there). However, this configuration does not contain just the difference from defaults. It has a number of items with "defcon" comments. When importing such a configuration, I run into the conflict right away - when processing these lines:
The same will happen later with the firewall configuration, there are some defaults too.

My use case is rather simple: I have two identical routers, one in use, one spare. I want to have my spare to be identical to the first one. I want to be able to get back online if my first one dies.

Is the best way to have the same firmware on both, "export show-sensetive" from the first one and then "/system reset-configuration run-after-reset=myexport.rsc"? If I understand correctly, "no-defaults" is not needed in this case.

Importing a full configuration onto a device which has its default configuration will fail due to duplicate items as you have found.

No, reset-configuration will restore the default, using no-defaults=yes will result in a completely unconfigured device ready for a full configuration to be applied. You can use run-afer-reset=... to apply the file. Once you have configured the user accounts you can use keep-users=yes to preserve them when performing the reset. Also note that certificates are not transferred by export/import.

There have been cases in the past where not all of the interfaces have been enumerated before the configuration gets applied and fails - the solution is to either edit the .rsc file and add a line :delay 10s at the beginning before copying it to the Mikrotik, or perform the reset, then connect by MAC address from Winbox and run import the .rsc file.

This is all such a complex topic... It's unfortunate, but there is no guarantee that an "export" will be able to be "import" without potentially minor modification.

If it the SAME router, the "backup" scheme seems like a better approach. The import/export stuff is useful, and you'd want to save a copy of that too. But the disaster recovery method for same router likely should be the backup file, as that has the config, and certs/users/etc. Backup should be relatively full-proof if same router to get you back to same state.

Now to "copy" a config to a new router, that generally takes some minor edits. So as you found the ":import verbose=yes" show the error, so that part is easy to fix (e.g. you need to remove those /interface/list lines). You should try using just a plain "/export" without verbose, and see if that has the errors.

Reason I suggest NOT using the "/export verbose" is that it has all the attributes. The idea is verbose includes defaults...while standard or terse just has the non-defaults. So sometimes starting with less config is helpful. If the normal one (e.g. NOT /export verbose) doesn't :import, I'd report that at help.mikrotik.com – the export should import into a clean router...

My use case is rather simple: I have two identical routers, one in use, one spare. I want to have my spare to be identical to the first one.

In this case you could actually use the binary backup file and restore it to the spare device. But beware that this will make both devices really identical, including MAC addresses of all interfaces. Which may not be what you want as it causes a few issues. The one most prominent one is that you'll inevitably loose management access to it even if using MAC connection. And you have to make sure that the active device is not in the same L2 network as spare when restoring config. After the restore is done, you can reset MAC addresses to their original values by executing
which will restore MAC addresses of wired interfaces. You have to change MAC address of bridge(s) (if MAC address(es) is/are set manually), if device has wireless interface(s) you have to reset MAC address(es) on that/those as well.

The amount of work involved in the process above is comparable to properly restore config from text export ... benefit of the above is that also users and certificates are transferred. And it only works between devices of identical model (and preferably same ROS version).