The idea of pg_prepared_xact_status function is that it allows to get status of 2PC transaction without any additional requirements to GIDs and any other additional information about participants of 2PC transaction.
This sounds kind-of like 1/4 of a distributed transaction resolver, without a way to make it reliable enough to build the other 3/4.
To make this practical I think you'd need a way to retain historic GIDs + their outcomes, and a way to prune that information only once an application knows all interested participants consider the transaction finalized.
I'd be all for a global xid status function if there were a good way to manage resource retention. But it's fuzzy enough for txid_status, which isn't really making any firm promises, just improving on the prior state of "no f'ing idea what happened to that tx, sorry". 2PC consumers will want absolute guarantees, not "dunno, sorry".
(Ahem, HeuristicMixedException raises its hand. You, sit down! You can only get that if you mix 2PC and !2PC xacts).
I can see it being useful for Pg to be able to report a stream of GIDs + outcomes for applications to consume. But unless you have either:
* some kind of app-controlled retention horizon and a way to multiplex it for >1 app (like slots do); or
* a node registry where Pg its self implements a full built-in transaction resolver;
then I think it's probably not going to get far.
I could see a full DTC resolver in postgres one day, once we have things like working in-core logical rep based multi-master with 2PC support. But that's a looooooong way off.