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