Using multilevel collations in a key with more than one field, FB uses interleaved keys.

For a key with fields (a, b):
- full key: <level 1 for a>...<level n for a><level 1 for b>...<level n for b>
- unique key for non-insensitive collations: same as full key
- unique key for insensitive collations, may use less number of levels: <level 1 for a><level 1 for b>

This doesn't cause any problem in these conditions:
- Non insensitive collations that compares strings as if it's comparing the keys
- Insensitive collations used in unique index, as the unique key is used there

For non-unique index (see TEXTTYPE_SEPARATE_UNIQUE in intlobj_new.h), the optimizer handle (or try :-)) the situation for index walking more or less as following:
    a = 'x' and b = 'y' => a starting with 'x'

For handling the non-unique side of a foreign key (when deleting/modifying the unique/primary side), the same code should be used there. But this code is using BTR_key which generate keys different than BTR_make_key (used in index walk) and doesn't consider the lower/upper retrieval attributes.

Test case:

create table pk (
    c1 varchar (5) character set utf8 collate unicode_ci,
    c2 varchar (5) character set utf8 collate unicode_ci,
    primary key (c1, c2)
);

create table fk (
    c1 varchar (5) character set utf8 collate unicode_ci,
    c2 varchar (5) character set utf8 collate unicode_ci,
    foreign key (c1, c2) references pk
);

insert into pk values ('a', 'b');
insert into fk values ('A', 'b');

delete from pk; -- should not be allowed

select * from fk;