> I gonna be honest with you, Rob, I'm a little frustrated

I'm sorry for your frustration.

> I really think this is the best design, and I see exactly zero downsides to it. I gave you the best example I can think of (user portal vs. employee portal).

It is important we get things right. The explanation you provided specified "how" two different session fixation protection strategies could be used, but it did not clarify:

* How would users of Spring Security process SessionFixationProtectionMigrationEvent differently than SessionFixationProtectionEvent? What are they trying to accomplish by handling the two events differently?
* Why would users of Spring Security process SessionFixationProtectionMigrationEvent differently than SessionFixationProtectionEvent? What are they gaining from a security standpoint from doing this?
* If we keep SessionFixationProtectionMigrationEvent, why would they want access to sessionAttributesWereMigrated from SessionFixationProtectionMigrationEvent? Please provide an example of when and why they would want this.

We want to ensure that we can answer these questions before adding SessionFixationProtectionMigrationEvent to the code base. Additionally, we want to be convinced that the examples are required for a majority of users. If there is a reason that a small minority of users might need this, then we can ensure we provide hooks to allow customization to support the edge cases. It is important that we justify the addition of code to keep the code base as simple to maintain and understand as possible.

If we cannot provide reasons at this time, just let me know and we can leave SessionFixationProtectionMigrationEvent out. If we come up with a reason later, there is a very easy way to introduce SessionFixationProtectionMigrationEvent passively.

> If that's just not going to be good enough for you, let me know now, because I'm going to have to essentially scrap it and do it again.

I don't think you need to scrap what you have. The feedback I have provided would require the removal of SessionFixationProtectionMigrationEvent and modify references to it to point to SessionFixationProtectionEvent.

> Unfortunately, I don't think I will have time for that for a long time. 

I did not want to make these changes without providing you the opporitunity to provde the answers to my questions in the event there is a reason to include SessionFixationProtectionMigrationEvent. If we cannot come up with any reasons and you are busy, let me know and I would be glad to make the changes for you.

> My biggest complaint about this entire process is how the requirements keep changing.

Both requirements and implementations can and will change...isn't that why the Agile Manifesto exists? You can find a few examples of changing requirements/implementations within the Spring portfolio below:

* The Java Configuration approach was changed from using FeatureSpecification to using `@Enable` annotations
* The second milestone of Spring Web MVC Async support required the implementation to change quite a bit to accommodate a bug that was discovered later on
* I have done three rewrites of the Spring Security Java Configuration code before it has been released once
* You can find countless commits within Spring's repositories with the comment "Polishing"

> I expect the "game changers" to come early in the process

Perhaps I am misunderstanding what you mean by "game changers", but I do not view the removal of SessionFixationProtectionMigrationEvent as a "game changer".

* The changes are rather limited, so I do not view this as a "game changer" in terms of coding efforts.
* If the code is not going to do what you need it to do, I could see my proposed changes as a "game changer" in terms of functionality. In this instance, please provide the answers to the questions so it can be considered for inclusion.

> I really wish you had said something about not wanting separate events the first day you reviewed it--when all indications were I just needed a few minor tweaks to make it acceptable.

I empathize with your frustration. While I would like to pretend I get everything right the first time, I (like you) am human and overlook things. As with the other examples I provided, it can take time to get code to be production ready and as we recognize ways we can improve the code we should make the necessary updates to the code. In short, I think it is important to make the code the best we can even though these questions did not get asked until after a few revisions.