I think that theoretically (meaning "if the feature sets work") then the gap is much closer in 9iR2 than in prior releases.

The obj$ update sets the expected maximum number of rows to a higher number, detailed in metalink note 194734.1 ...

Error: ORA-28606 (ORA-28606)
Text: block too fragmented to build bitmap index (%s,%s)
---------------------------------------------------------------------------
Cause: The block(s) exceed the maximum number of rows expected when
creating a bitmap index. This is probably due to maximum slot
allowed set too low. The values in the message are: (slot number
found, maximum slot allowed)
Action: alter system flush shared_pool; update tab$ set spare1 = 8192
where obj# = (select obj# from obj$ where NAME= AND
owner# = ; commit;

.
I believe there is a similar workaround for a problem with "minimize rows per block" and partition exchanges, where spare1 is higher for the non-partitioned table than for the partitioned table.

I forgot to mention another problem. DBMS_STATS.GATHER_TABLE_STATS() with 'cascade=>true' won't work for function-based indexes. Or was that 8i? I forget now.