>> Why can you have more than one <http> section in the namespace configuration? (http://static.springsource.org/spring-security/site/docs/3.0.x/reference/ns-config.html) I don't think I have a good enough concrete example for you. In every case I've ever used Spring Security, I only had one <http> configuration.

Supporting multiple <http> elements allows for protecting a single application that acts as both a service and a web application differently. For example, you may expose the same endpoint that delivers HTML to the browser and JSON to services. Authentication is likely to differ quite a bit when dealing with such situations. In this instance, multiple <http> elements are very useful. You can see this approach is used quite heavily within the Spring Security OAuth applications.

>> Without separate events / sessionAttributesWereMigrated, they developer has no way of determining how the session was changed/migrated.

This is true, but what value is there in stating in how the session fixation protection event was performed? From a security standpoint, what would a developer want to gain from this? In both instances we are stating that session fixation protection was performed.

>> Someday somebody will try it. If I've already written the code to account for it, what does it matter? It would take MORE work to UNDO it.

Spring Security will never solve all cases, but should allow others to extend it to meet edge cases. Before we add both events I think we need to be able to answer why would being able to distinguish between the two events benefit an application from a security standpoint. I'm not saying that there isn't an answer to why...just that off the top of my head I cannot think of any (perhaps you have an example).

Another point is if we need to, we can easily make the changes passively (one event extends another). However, if we add it now we cannot remove it