You're right that there's no trace why '_' is dropped over '<>'. I don't recall why either.

I do have one reason though. I frequently use '_' as an argument in lambda list when I don't care what is passed, e.g. (map (lambda (_) #t) lis). But inside such functions I won't be able to use (is _ < x) for the '_' here won't match the literal '_'.

It isn't a showstopper; after all, It can happen for any other literal macro keywords such as else or =>. We do need to consider the convention, though. It's less frequent that someone accidentally use <> as a parameter variable.

If we go with '_' as a placeholder, a better future direction would be to establish a convention to use _ as a syntactic keyword to show don't care argument in the lambda list. E.g. make (lambda (x _ _) something) valid if you only use the first argument. Then, as far as srfi-156 definition imports the same syntactic keywords, shadowing won't be a problem.