Hints are just that -- Hints. They may (and will be) ignored at the whim of the server. Not only that -- but a fast full scan does not return data sorted (proof by simple example below).

Your ONLY option for a correctly coded application, if you need the data sorted, is to use an ORDER BY. A subsequent upgrade, someone analyzing statistics (or analyzing them differently then they do today), data skew over time, any number of things -- can and will change the plan (even if it works). Never rely on a "plan" to have the data ordered -- you can ONLY rely on order by to order the data.

Fast full scans on the index are defined in this fashion (designing and tuning reference):

<quote>
This is an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULL constraint. Fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation. It reads the entire index using multiblock reads (unlike a full index scan) and can be parallelized.
</quote>

<quote>
Using Fast Full Index Scans

The fast full index scan is an alternative to a full table scan when there is an index that contains all the keys that are needed for the query. A fast full scan is faster than
a normal full index scan in that it can use multiblock I/O and can be parallelized just like a table scan. Unlike regular index scans, however, you cannot use keys and the rows will not necessarily come back in sorted order. The following query and
plan illustrate this feature.
</quote>

Your data is currently perhaps being returned in sorted order TODAY but it does not have to be and will not be over time!!!

Here is the conclusive proof of that:

ops$tkyte@DEV816> create table t
2 ( x int not null,
3 a char(2000) default rpad('*',2000,'*') not null,
4 b char(2000) default rpad('*',2000,'*')
5 )
6 /

Table created.

ops$tkyte@DEV816> insert into t(x) select rownum from all_objects where rownum < 10
2 /

9 rows created.

ops$tkyte@DEV816> create index t_idx on t(x,a)
2 /

Index created.

ops$tkyte@DEV816> begin
2 for i in 1 .. 5
3 loop
4 delete from t where x = i;
5 commit;
6 end loop;
7 end;
8 /

PL/SQL procedure successfully completed.

ops$tkyte@DEV816> begin
2 for i in 1 .. 5
3 loop
4 insert into t (x) values (i+100);
5 commit;
6 end loop;
7 end;
8 /

PL/SQL procedure successfully completed.

ops$tkyte@DEV816> set autotrace on explain
ops$tkyte@DEV816> select /*+ INDEX_FFS(t t_idx) */ x from t
2 /

X
----------
101
102
103
6
7
8
9
104
105

9 rows selected.


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=82
1 0 INDEX (FAST FULL SCAN) OF 'T_IDX' (NON-UNIQUE)

This is why we do the explicit order by at the end -- an index fast full scan does not return the data sorted in general!!!!

There is many dozens of ways to get the results above and it will happen naturally as the index grows and splits over time -- an index fast full scan is most definitely NOT sorted.