You could read a book in Aoede, but you couldn't find anything in it. Now ⌘F (or a toolbar button) opens a slim find bar in the reader: type, see "n of m," step through the matches, close when you're done. On the Mac, ⌘G and ⇧⌘G step forward and back and Esc closes it. Every match gets a cool-toned underline beneath the reading highlight (the word being spoken still wins the color), the current one drawn stronger, and tapping a match starts reading from there. Find never moves playback on its own. It only scrolls, so you can look ahead while the voice keeps going.
Search also widened to the whole library. The book list is searchable now, and a query swaps it for results grouped by book with the matched phrase emphasized in each snippet; tap one to open that book at that sentence. Underneath is a per-sentence index in SQLite with a normalized column I scan with LIKE. I skipped full-text search on purpose: FTS has a minimum token length that quietly drops short queries, and a lot of what I search in Japanese is one or two characters. A plain normalized LIKE behaves the same for English and Japanese at any length. The normalizing folds away case, width, and accents but keeps kana distinctions, because in Japanese that difference is meaning, not noise. Books imported before the index existed get backfilled once on launch.
The part that ate the most time wasn't search, it was where search sends you. Jumping to a hit near the end of a long book used to animate the whole way there, a disorienting whoosh through content that hadn't rendered yet, and the scroll would chase rows it couldn't find and land in the wrong spot. Long jumps now snap straight to the target (anything past ten to fourteen segments, depending on platform), while short ones still glide. Getting "instant" to actually mean "on the right line" took a few passes, ending with the target row reporting its real position the moment it lays out, so the scroll corrects exactly onto it instead of guessing from estimated row heights.