I'm not so sure to be honest. Mostly for two reasons:

1. I don't think I'll have the bandwidth to properly review such changes.
2. I worry about the hits to compile time and binary size.

For (2), I think memchr is already teetering on the edge of what some might consider a "small" crate. It sticks pretty strictly to case sensitive substring search, but there is a lot of space to explore if its scope were increased to include inequality comparisons.

When I've needed inequality comparisons, I myself just wrote what I needed in lieu of adding it to this crate.

With that said, I'm not 100% against it. Because at least in terms of implementation, I do believe it would be very similar to what memchr already does, and memchr already has a fair bit of infrastructure in place to make supporting something like this across platforms. So if there exists a small & flexible API that doesn't add too much code to the crate, and can be done in a way that is opt-in, I might be open to it.