I’m still not following - I don’t believe Kodi let’s you have more than one path per content item?
So…by ‘the content is the same’ - do you just mean you’re pointing each of these separate DBs at the same content? …so Kodi is indeed filling/maintaining multiple DBs, right? And if so, what advantage is there to using MySQL vs the standard Kodi DB in that case?
Or have you managed to work out a way so that all the meta-info is in one single place, but somehow the paths aren’t?
(I personally use NFS, which lets one normalise paths across those platforms, so that one DB is truly one DB).
As for “clear issue” - putting it in quotes doesn’t make it not exist 
Nice for you that you haven’t run into it, but it doesn’t take much browsing here (once you know about it!) - or at the Kodi or UnRaid forums - to see that plenty are. This post documents it really well - The state of MariaDB in the context of CoreELEC
I’m probably just not understanding you, and apologies if I am not - but the classic point of MySQL with Kodi is to have one single centralised store, for everything. Which means Kodi does less scraping (vs. multiple clients), all clients have an identical, consistent view on the data (any changes made appear everywhere etc), and watched points are all synced etc etc. As soon as you move to any multiple database approach, it seems to me you’re just adding complexity for no functional gain over the in-built sqllite stuff?