cmasurpa is correct. Any setup that is perfromed during the enter remains un-updated until the enter transition is fully complete. In the example you give, mario needs to begin the state suspended in the air, something that could reasonably be done in the enter method. If the enter method is called before the enterance transition (as is the case after the update), then mario will be placed in the air, the new state will slide/fade/blink/or generally transition in, and then the new state will start calling update and mario will fall in, as expected. If enter is called after the enterance transition, then the new state will slide/fade/blink/or generally transition in before mario is placed in the air. Once the transition is complete, mario will be placed in the air, and then the new state will start calling updates and mario will fall in.
This second approach (the one that Slick was using before) has two problems:
first: It is possible that the enterance transition will try to render the new state before the transition is complete (eg. fade in, slide in). If this is the case, then you will have very little control over where mario is positioned while the state is fading in/sliding in/transitioning in. This causes a sudden "jump" at the end of the transition when the enter method positions mario in the air.
second (less common): It is reasonably possible that the enter method will take a noticeable amount of time to for the enter method to finish if mario is accompanied by a sufficiently large level. This could cause a visible delay between when the game transitions in and when mario begins to fall. Such a pause would be more likely to go unnoticed between the exit transition and the enter transition.
I still believe the changes are good, but I apologize for commiting them before they were fully discussed. I believed, at the time, that this change was a relatively minor bug fix, and that everyone was sorta okay with it.
"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"