Hi Meredydd,
In hindsight, it seems clear but just to confirm maybe for other newbies: Is it correct to say that the row_id changes, when you clone your app? In my case, I seems to be the first part of the two-part-list only. However, if true, this makes the row_id not a valid candidate for a stable external user-id, in my view.
Thanks, Franz
If you clone an app to the same account, the original app tables will be duplicated. It is impossible for the rows of two different tables to have the same id.
The only way to keep the same id is to keep the same table. You can do that by deleting the tables created during cloning and sharing the tables of the original app in the cloned one.
If you clone an app to another account, the original app tables will be duplicated. Again the row ids will be different because they belong to different tables.
I don’t know what you mean by “stable external user-id”.
In my company we have one user table shared across all the apps, so I could use the row id as a stable row identifier across all the apps.
PS
Please create new posts with links to old ones rather than reviving old posts that already have an answer. 
Dear Stefano,
Thanks for the clarifications and for putting my question into its proper place. I was - before the exercise - not entirely sure whether the ID given was indeed the actual row-id of the database or an additional layer of abstraction. Forgive me for assuming from meredydd’s much appreciated answer to point 3 “any database circumstances…” the former. That is why I added the question to that closed entry: The ID is not stable when it is recreated by cloning.