My responses (in order of your questions):

- A developer should rightly know what action was taken to protect from session fixation. Right now the only option is that the session is migrated, however there could be other approaches in the future. As a concrete example, SEC-2135 will add a `SessionFixationIdChangedEvent extends SessionFixationProtectionEvent`. An application may have different HTTP configurations with different session fixation protection strategies. I would accept an argument that `SessionFixationProtectionEvent` should be abstract.
- Partially same as above (developer should know what action was taken, application may have different HTTP configurations with different strategies). If only Spring attributes were migrated instead of all attributes (or vice versa), developer may need to add (or remove) certain session attributes, so he would need to have this information.
- My typical approach is for boolean method calls to "make sense" when read in English. For example, `if(sky.isBlue())` "makes sense" (if sky is blue) and also follows standard JavaBean conventions. However, `if(event.isSessionAttributesMigrated())` is nonsensical (the event object is the representation of something that happened in the past and "attributes" is plural, so the JavaBean `is` doesn't work for many reasons). `if(event.sessionAttributesWereMigrated())` does make sense. I believe a switch to `isSessionAttributesMigrated` or `getSessionAttributesMigrated` would be a disimprovement. I'm open to suggestions for a better name overall, but I couldn't come up with one that I thought made it clear exactly what it meant. (Self-documenting code is what we're talking about here.)