In my case I also not migrating any configurations from one router to another. I have configuration backups but never actually restored them, just sometimes manually running /export terse verbose remotely into the file over SSH.
Just like like this:
for host in ${@} ; do
mkdir -p "${host}"
ssh "${host}" "/export terse verbose" > "${host}/config.rsc"
done
So I suppose this can’t cause any issues for sure.
However my case become more frequent (for last couple of days at least) and I set debug logging for everything. Is still investigating what is happened but for now the only thing looks strange to me is “Unsupported capability received” messages router receives from GoBGP instances (I actually have only Mikrotik and GoBGP for BGP for now, so Mikrotik connections don’t have such messages while GoBGP’s do) with various status codes:
# One sequence which look like happened during the same handshake
Starter {openOk: false} Unsupported capability received, code: 6
Starter {openOk: false} Unsupported capability received, code: 69
Starter {openOk: false} Unsupported capability received, code: 73
Starter {openOk: false} Unsupported capability received, code: 71
Starter {openOk: false} Unsupported capability received, code: 70
# Another one
Starter {openOk: false} Unsupported capability received, code: 73
Starter {openOk: false} Unsupported capability received, code: 5
Am I right guessing these codes are actually capability codes: https://www.iana.org/assignments/capability-codes/capability-codes.xhtml ?
I also have pretty often route recalculations while there’re no new actual routes received. Since the first portion of Unsupported capability messages are received from my own software built against GoBGP as a library I have a chance to perform some experiments and actually know what it does. For now it looks like Mikrotik do recalc on every route pushed via BGP without any check for current routes and their prefixes but I will check it deeper.
Second portion of unsupported capabilities (with 73 and 5 codes only) is from Cilium, so it doesn’t look we both done something wrong at least the same way 
My main theory for now is improper BGP message handling causing recalc which making routes mechanism stuck at some point. Anyway no proofs for now, just a theory. Will keep you tuned folks.
And thank you for your thoughts, they are really valuable.
PS. About netinstall, I understand this could help and that’s a fast way, but I prefer to know what goes wrong deep inside, so will keep this option if I become too lazy or too old for that stuff. Btw, one of the options to isolate this behaviour is to switch to GARP instead of BGP for all of non-Mikrotik peers, that looks possible for my case but will require some renumbering in some services, how ever it doesn’t look insane - just a coupe of DNS changes and IP address changes - this will exclude all of GoBGP stuff from Mikrotiks and will leave only Mikrotik peers and static routing for others in my network setup.
