In summary, the problem is that if you modify an Infotable that's a persistent property of a Thing (e.g. by adding a row) and then restart the server, the data is lost.
The solution provided in the above discussion -- more of a workaround really -- is not an efficient one. It is to clone the Infotable, modify that, and then replace the original Infotable property with the cloned one.
Worryingly, I have been assured that this behaviour is not a bug. If that's really so, then it seems like quite a serious design flaw because there's nothing to prevent use of an Infotable's setter-like services [when it's a property] and nothing to warn that such changes are likely to be transient. Even some of the experts on this forum weren't aware of the behaviour, which does rather imply that it's not intuitive.
Perhaps when creating or viewing a property that's an Infotable, a permanent warning can be shown saying to clone it before updating it. (If anyone balks at this idea because it won't create a good impression, I can only apologise and refer them to the statement that the behaviour is not a bug.)
The behaviour it's not a bug as far as I know, and when you know the whys you can understand.
You should live with it ( it's not a big pain when you know it ), but I agree with you that there should be a big warning somewhere telling the right way to modify persistent infotable properties.
And Infotable properties are not for everything, sometimes it's better to store data on DataTables. Infotables are more meant for fast access data or small configuration settings ( for that you also have Configuration Settings on Thing's - which I don't use - ).