Regarding the code details:

• Is it necessary to use a Box with custom styling for the search results? Can a ListBox be used. Need to think about eventual porting to Gtk4. Note that Dialog is deprecated in Gtk4.
• It is usually easier to use the markup property of labels rather than using AttrList.
• In prep for Gtk4 try to use EventControllerKey to handler key presses
• In prep for Gtk4 avoid moving windows or playing with their positioning. That should be left to the window manager
• There are a couple of new signals in GitManager that it appears nothing connects to - can these be removed.

All of these have been addressed.

Thanks for working on this. It is impressively fast. There are a few comments:

• I'd like to see a close button on the search dialog. Maybe better would be to insert it into the sidebar so it is always available without knowing a shortcut, but that could be left for another PR (may be easier if the feature is in main code)
• I do not like <Ctrl>P as the shortcut as that is usually used to show a print dialog. Maybe <Alt>F would be more memorable?
• Not sure that the dialog should be modal and close after selecting a file - the user may want to find/open more than one file.
• I think the results should prioritize files that are in the currently active project
• Some very fuzzy matches are prioritized over what appear to closer matches. For example searching for "Sea" in the Code project gives "spell.vala" as the first result, "Settings.vala" as the second whereas "Searchbar.vala" is only third.
• The search also shows non-text files which cannot be opened in Code. These should be filtered out or at least not opened

All of these issues have been addressed except being able to open multiple files. I'm still unsure about how to implement that.

I ended up changing the dialog that the fuzzy search appears in into a popover:

Because of this change, the fuzzy search can also be dismissed by clicking outside of the popover.

Thanks for the improvements - I'll retest for a while. The muli-file issue can probably be left for another PR. The Files app has the same issue - selecting a matched file closes the search and if the selected file turns out not to be the desired one you have to repeat the whole search again (which could take a while).

A logical solution might be to use <Ctrl>Click to multi select items in the same way as in e.g. a Files view.

The plugin now does indexing in the background

One thing I would query is how fuzzy the search is and the ordering - some of the results appear only remotely related but prioritised. E.g.with the Code and Files projects open, entering "cv" finds "class.svg" in Files and lists it higher than "cv.po" in Files.

Would it be better to allow use of wildcards or regex or require matching at least 3 consecutive characters?

I think that has something to do with the fact that when multiple projects are opened, the paths used when calculating the search score in plugins/fuzzy-search/fuzzy-finder.vala has the project name added to the start of them. This code was there before I started working on the plugin:

// plugins/fuzzy-search/fuzzy-finder.vala
if (project_paths.size > 1) {
    project_name = Path.get_basename (project.root_path);
    path_search_result = fuzzy_match (search_str, @"$project_name/$path", cancellable);
} else {
    // ..

Removing this code should fix the issue you're describing.
Also, tweaking the value of CURRENT_PROJECT_PRIORITY_BONUS may help too.

I think that the use of wildcards, regex or requiring at least 3 consecutive characters are solutions to try only if the suggested fixes above don't work.

Yes, as long as the desired matches come first it doesn't really matter if there are remote matches further down.