This happened because "joining" wasn't cleared until the player was ticked. Runnables (presumably) ran _after_ the player list packet was sent, but before the player was ticked; thus, the player list packet was sent, but not cleared. The fix is to replace joining with hasSentListPacket, which is set immediately before sending any player list packets (thus, if hidePlayer is called after, it sees that the list packet has been sent and sends a new one to reset it). With this fix, the player is added to the list and then removed shortly afterwards.
The reason why running /hideall in the example wouldn't fix the invisibility is because the server already thinks the player's been removed from the list (as they're hidden), and thus doesn't want to send another hide packet. This is correct behavior assuming that they get hidden correctly the first time, which they now do.
Cross world teleportation works by taking a copy of an entity and moving it to a new world. After this happens the original entity is marked as dead so as to be removed from the original world, however it still undergoes one further tick in the main world, but with some information from the new world. It is not so easy to break out of this tick cycle if needed, so instead we move the portalling process towards the end of an existing tick. This ensures that the entity will not be spuriously ticked.
This is highly useful for profiling vanilla code, and in some cases plugin code. It is somewhat expensive, though, which is why it was initially disabled.
I chose to use a system property instead of a configuration setting because 1) the MethodProfiler is exclusive to CraftBukkit and not part of the general API (the timings system is the general API equivalent), and 2) using a static final boolean property _may_ allow the JITter to optimize out the methods when disabled (though I'm not sure of it).
There are several changes to fix cases where the profiler code was broken slightly by other craftbukkit changes. All of cases have been fixed, except for the block entity ticking one, due to the cost of the getSimpleName call. For that, a ticking entry is used instead, so that time spent actually ticking the block entities can be compared with time processing the list.
This (effectively) reverts 7dde6cc566.
