If you execute the script above you run into a problem with transaction isolation. I actually had a similar issue some time ago. The thing to keep in mind here is that the transaction going for Bob does not see changes made by the Super engine because the transaction is still going and the isolation does not allow for an uncommited read. Postgres has extensive documentation about this but the essence is: An uncommited read is not possible in postgres.
And your solution, obviously, is to commit your changes from the Super engine first, then work with it in the other transaction. If have not tried it but my guess is that you have to stay on the default Read committed isolation level (as higher isolation wouldn't allow to detect changes since a transaction - in this case Bobs - has started).
Thus, before executing Bobs query:
oSuperEngine.execute("COMMIT")
However, this raises a side issue that effectively breaks the awesome thing transactions bring you: You cannot roll back easily since the changes are already commited. What you'd basically want here is the opposite of a savepoint:
Whereas a savepoint does not store changes to the database yet, it ensures a rollback would only go back to a particular point, not all the way. You'd want the opposite: Store it in the database but be able to roll back and remove it from it again. I am not aware of such a thing and I highly doubt it exists since it would violate the principles of transaction isolation.
My solution to this problem was to write custom rollback routines that I would call on an exception so that I could manually undo the changes. This is quite a bit of work though and is high-maintenance in the long run. In the end, in my case, I reconsidered my solution and dropped the multiple-engine approach (but that is a decision you have to make yourself).