I've found what I think is quite a serious issue. I've reproduced in 11.6 and 11.7.4. A prostrct repair on a database with an st file with fully qualified storage area locations which are wrong can lead to the BI getting out of date. Steps to reproduce:
** The database was last used <date/time>. (886)
** The before-image file expected <date/time>. (887)
** Those dates don't match, so you have the wrong copy of one of them. (888)
In my opinion this shouldn't be allowed to happen. There should be some sort of control in place that stops the prostrct repair from happening - particularly against files on a running database.
A .db file contains the pathes to all database extents.
Db extents do not contain a path to their parent .db file.
Prostrct repair is unable to check if more then one .db file is linked to the same db extents.
Prostrct repair just updates the headers of db extents based on information it read from .db file you specified in its command line.