No. It is not a bug, it was my mistake.  I've just tested  several versions of 389 and FDS (1.2.x, 1.1.x and 1.0.4). They all exhibit the same behavior concerning the sorting of CNs in VLV browsing.

So then i still have this second question - is there a way to change the vlv index sort in order to sort according to nsMatchingRule? Or it would be a feature request?

*)  i've tried to add collation rules to vlv index entries but putting  the       value       of       the      attribute      vlvSort      to  "cn:2.16.840.1.113730.3.3.2.18.1.6"   or  to  "cn:fr". It   does  not  work. Instead of changing the sorting order it produces some strange  contents in the index vlv#outlookbrowseindex.db4 file.

**)  then  i  thought that maybe i should change the cn index ordering and i have added "nsMatchingRule: 2.16.840.1.113730.3.3.2.18.1" to the cn  indexes  in  dse.ldif. However reindexing does not  actually change the  order in cn.db4  (even  after  reindexing by smth explicit like db2index -n userRoot -t cn:eq,pres,sub:2.16.840.1.113730.3.3.2.18.1 ) in the index .db4 files.