The only thing that's "wrong" with return is that you have more than 2 return codes. You have found, not found, and possible error conditions. To handle the error conditions, you will still have to wrap find() in an eval block. I would rewrite your call as such:
It looks like a lot more code, but so does the part() example in Exegesis 6. I still liked the flexibility it gave me.
Now, the system I seem to be proposing here involves using try-catch (or eval-$@) syntax throughout the entire application, including all callers. To me, this isn't something you can just implement in one part, but not the other. I would completely eschew return for status codes and use it only when there is something to actually return, other than true or false. (Speaking of truth/falsehood, you could rename the signals to Signal::True and Signal::False and collapse the number of signals you're working with. But, I prefer to have all the signals explicitly named.)
As for the worry that you're propagating a bunch of classes, you could have each class define the signals it happens to the only user of, so that the useing of the class auto-uses the signals for that class. TMTOWDI.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.