GiST a second class citizen?

The PostGIS project has been making use of GiST for about a year now and
(thanks to the excellent work of Oleg and Teodor) have found it to be a
most excellent indexing system.

We are about to apply for some government R&D funding, and one of our
potential subprojects is creating GiST bindings for all the standard SQL
PostgreSQL types. Why? Well, because our spatial indexes are GiST,
providing bindings for the standard types allows us to do multi-key
indexes which combine spatial and non-spatial data. That would be pretty
unique in the DMBS world as it stands right now.

So far, GiST is integrated into the main tree, but all the bindings seem
to be kept outside, in contrib (ltree, btree, rtree). If there were a
complete set of GiST b-tree bindings available for the builtin types,
where would/should they reside? Would I be completely out-to-lunch if I
suggested that the GiST bindings might even replace the standard ones?
The ability to multikey indexes of wierd-and-crazy-types with
normal-boring-types seems like a halmark of a Real Live
Object-Relational DBMS.

Thoughts?

Paul