... das ist so gewollt, dass das qualifiziert zur Compiletime vernagelt wird - bei Triggern regt sich keiner drüber auf. Ein Schema und eine Library werden zwar beide als *LIB implementiert, aber konzeptionell sind das zwei völlig verschiedene Dinge.
Verbiege ich nun die Sache und erstelle Datenbanken (= Schema), die verschiedene Bibliotheken überspannen, bekomme ich save restore Anomalien, die ich mir möglichst erspare - die schlagen nämlich im Wiederherstellungsfall unbarmherzig zu (logische Dateien, die auf den falschen physischen hängen, kaputte Objekte, wegen nicht auflösbbarer Referenzen...).
Ganz crude wird es, wenn man Datenbankobjekte nach *LIBL zugreift (beliebt sind hier unvollständige Testumgebungen, die durch dahinter stehende Prod Bibliotheken "ergänzt" werden). Zugriff dann nach dem Muster: ich habe hier eine Auftragsposition, schau mal, ob Du irgendwo eine Position findest und schreiben darfst Du nur, wenn die Artikel irgendwo vorhanden sind - und das mit einer Datenbank, die referentielle Integrität sicherstellen kann.
Je nach vorhandenem Wahnsinn, kann man dann Dateien noch mit share öffnen lassen...

Es gibt Umgebungen (leider viel zu viele), die bereits so verbogen sind, dass man das kaum wieder grade kriegt, aber wenn man die Wahl hat nimmt man Datenbank (alles kommt innerhalb einer Bibliothek zum Abschluss) und nicht Datenschrank.

D*B