Well, I can't think of anything to say that you've not heard of before, nor haven't thought of yourself, for that matter...
The key is to try to do whatever can reasonably be done to minimize the divergence of the source tree. "minimize", not "prevent" because the latter's not possible unless they give up the usage of SQLJ, etc.
I think an important point to stress is that we understand the above, and have realistic hopes in this area. Stress that even small steps in that direction can greatly reduce the hours of effort needed to maintain a port for another RDBMS. I wonder sometimes if this hasn't been missed, if instead there's a feeling that it must be "all or nothing".
Of course, the db_* API is an "accidental" step in that direction since we can massage all queries from within the API ...
Since aD just went through the exercise of hacking through each and every source file, switching to the new db_* API and ad_page_contract scheme, they probably have a much better sense of the effort required to port to another RDBMS. Hopefully this will translate into a better appreciation for just how much leverage they can gain by modestly supporting OpenACS.
If aD is serious about supporting OpenACS and an InterBase port (and I think it's foolish to start an InterBase port outside of the OpenACS effort, but that's just my opinion), they should consider funding a technical coordinator along with Adam's non-technical slot. With logistical support from aD, I think our community can come up with plenty of help supporting both IB and PG. A techical person could help with a lot of the stuff Ben's done, i.e. CVS tree maintenance, scheduling and making releases, Q&A (!), keeping the OpenACS community apprised of upcoming work that will have an impact on the IB and PG ports while at the same time helping aD engineers understand what hurts and what helps us, etc etc.
These are just some things off the top of my head ...
