Hardly a bug, since it's doing what was asked -- "Find all the notes containing pattern in their title". Feel free to submit a "Change Request" ticket
Hopefully the context in the list items will help you decide which note to use, assuming we can't find a way to omit items in the Trash.
The returned ZTEXT strings are (generally) multi-line -- one line for the title of the note, lines for each paragraph in the note, so lots of line endings. By replacing those with %Space% and then replacing the custom row delimiters with %LineFeed% we're able to use LINES() to get the number of records returned (remembering that even zero records is a line, but with no characters) and a "For Each: line" to work through multiple records.
The replacement happens before the multiple-results logic, so it's not that. I suggest you dump Local_notes to file before and after the action to see what is(n't) happening and why. I've a feeling this'll be something only you can solve, it being related to some specific note text, the number of results you are getting, or similar. It's just a global S'n'R, so I can't see why it would sometimes just skip a match...
Actually, the "omit notes in Trash" was easier than I thought. Looking at the schema again, field 17 is ZTRASHED and, sure enough, that is 0 normally and is set to 1 when the note is moved to the Trash.
So all we have to do is add that to the search term, changing the last bit of the SQL command from:
WHERE ZTITLE REGEXP $KMVAR_Local_regex
...to:
WHERE ZTITLE REGEXP $KMVAR_Local_regex AND ZTRASHED = 0
New KM "Execute Shell Script" action's script in full:
sqlite3 -newline '==myKMNew==' -separator '==myKMCol==' "$KMVAR_Local_dbPath" "SELECT ZTITLE,substr(ZTEXT,1,200),ZUNIQUEIDENTIFIER FROM ZSFNOTE WHERE ZTITLE REGEXP $KMVAR_Local_regex AND ZTRASHED = 0;"
