You've pretty much answered the question yourself when you mentioned forking. We decided we didn't want to fork at the time, though that was certainly discussed as a possibility. With the toolkit changing so rapidly at the time, we decided it was advantageous to be able to quickly import new aD code.
char(1) vs. boolean isn't really much of an issue, as PG stores bools as 'f' or 't' anyway (or at least outputs them in this form, it accepts 'false' or 'true' for input, too). Sticking with char(1) was easier. The queries work unchanged with either datatype.
That's also why we added things like sysdate and the dual view. More queries ported without change this way.
With ACS 4x I intend to use bools in the datamodel. We will rewrite queries into SQL'92 form when possible, for the very reason you mention (compatibility with other dbs). When that results in a query that won't work with Oracle, we'll use the query dispatcher to choose which query to run (i.e. the Oracle one or the PG one). When it results in a query that does work with Oracle, we'll just change the query directly. coalesce vs. nvl, that kind of thing.
As far as writing for 3x vs. 4x, timing should play a factor in your thinking. If you need to roll out a site in the near term, you'll be using OpenACS 3.2. If you don't have a pressing need for the module, consider downloading Oracle and write it for 4.1, doing your best to avoid Oracle-specific features. Then rewrite the necessary queries for Postgres. We're interested in providing modules that will work with both Postgres and Oracle (and later IB, etc) when possible. That won't be a requirement, obviously, and some folks could care less about Oracle.
But ... if a module writer can support both easily, why not do so?
