There appears to be a bug for the Ignore diacritics option for Find As You Type and the Filter Bar as each mode return different results.
For example, with the option enabled for both modes, and the Default mode set to Find, typing o will match an item with an ø in the name (as expected). However if the Default mode is set to Filter Bar, typing o will not match the ø item. Even with the Regular expression option disabled for the Filter Bar the discrepancy between the two Ignore diacritics remains.
If this turns out to not be a bug, perhaps the option names could be differentiated in some way, or at minimum the difference in behaviour outlined in the docs? From a user's perspective, a duplicate option "Ignore diacritics" would be assumed to behave the same regardless of mode, and when it doesn't, the assumption is that the program is broken in some way, or at the very least, the UX is negatively impacted.
This seems to be due to differences in the underlying APIs that the two controls are using.
Without getting too technical, the FAYT field uses the FindNLSStringEx function with the LINGUISTIC_IGNOREDIACRITIC flag. This function performs a simple sub-string search which is what the FAYT needs.
However, the Filter Bar needs to support full wildcards, and so it uses an alternative technique of calling NormalizeString to decompose the composed characters (e.g. Ä becomes A + ¨) and then removing the non-spacing characters like ¨.
It seems that FindNLSStringEx considers the Ø character to be a diacritic, but NormalizeString for some reason isn't able to decompose it. I haven't spent much time looking into why but my guess is it's actually a letter in its own right, rather than a composed character (Unicode doesn't seem to have a separate / composition character anyway).
I'm not really sure which of the two behaviours is correct, but I agree it's confusing that they're different. We'll add a kludge for Ø in the next version to make the Filter Bar work the same as the FAYT, at least until we can find a better solution.