I much prefer this behavior. In general, I feel like "responsive search" (or whatever it's called) is a UI feature that was added because it's technologically "cool" to the developers, but without any consideration of whether it's actually beneficial to the UX. I know what I want to search for. "Responsive search" just makes it take longer for me to input that query and causes the terrible user experience of having a long delay before the characters you have typed are displayed in the input field.

The argument against this change in behavior is that people may already be accustomed to the previous behavior and after the change might sit there waiting without realizing they need to press Enter "why isn't the search working".

I think the alternative proposed by facchinm of automatically searching after a delay is a reasonable solution in light of the historical Library Manager search UI. I suppose you could even start with a relatively short delay on the first release and then increase it on each release if you wanted to provide a gentle transition to the users.

Another option if you want to completely leave the "responsive search" system behind would be to add a "Search" button on the right side of the search input field. I think this new UI element would act as a signal to the user that some action needs to be taken to submit the search query (whether the chosen action is to press Enter or to click the "Search" button). They're not going to sit very long waiting on the search to automatically start before noticing that button and clicking it. After that first time, they'll have learned to use the new system and won't have any further problems.

Very nice facchinm!