The problem is that the beans within a chain are not first class beans (from the application context perspective); even if we gave them ids, the beanName would not be automatically populated; we'd have to add code. We added the ...handler#n stuff to provide some context in a Spring Insight trace and so getting it in the exception in this context was "free". In fact, even if we populated the id, currently, the chain would overwrite it with this value.
Given that there's a reasonable (albeit not perfect) solution, you are right, it would likely not get high priority but feel free to open a JIRA if you feel strongly.
Yes, the filter could throw its own exception, but it will be wrapped (become the cause of) a MessageHandlingException.
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware