I have to disagree with your decision. No mobs will move while levitating, their AI is shut off. However slimes have a different movement pattern in the code. As opposed to zombies or skeletons which choose a target and slowly move towards it, slimes choose a target, get a velocity set (MC-87573 says this defaults to east) and don't "recalibrate" until they land again. If a slime is affected with levitation, it basically never recalculates or changes its velocity (because its AI is off), causing the drifting we see.
If you read this and still want to close the issue, it's not my place to argue. After all, this is an extremely obscure bug that will never effect most players, but bug it is. Thanks for actively moderating both here and /r/minecraft.
Can confirm. Furthermore, I'm almost certain this is because of the change to Passengers vs. Riding, because of other difficulties like jockeys not working.
This is probably works as intended, so you can't have an enderpearl in your second slot and just switch to that right after throwing the first one. Unless you mean that the second enderpearl should only show-up white after you switch to your second slot.
+Marcono1234 Thanks. I figured it was probably possible, but didn't know how.
That was quick. I ran a test and it does work with levitation 1. Updating bug report now.
But the effect works, it makes the slimes float. Unless you mean that Mojang won't fix bugs caused by amplifiers greater than 4, in which case I'll update the bug report. I'll have to do more testing, but this should work with any level of levitation.
If you read the description of both issues, redstonehelper, you'd see that they're totally unrelated. The potion effect here works fine, I'm reporting a fluke in slime AI. Besides, this is levitation, not haste, and this works perfectly for all mobs except slimes.
My testing shows that this is fixed in 14w30c.
I can confirm in 14w27b. I was using a clock with this command: /replaceitem entity @a slot.hotbar.8 bow and when I removed the bow from slot 9 (8 according to command) it did not give me a new one. I did further testing and by tossing out the bow and then getting a positive comparator output off of this command: clear @p bow 0 0 I confirmed that for some reason it is giving you a ghost item or thinking you have the item even after removing it.
P.S. This is a duplicate of MC-59176
I can confirm in 14w27b. I was using a clock with this command: /replaceitem entity @a slot.hotbar.8 bow and when I removed the bow from slot 9 (8 according to command) it did not give me a new one. I did further testing and by tossing out the bow and then getting a positive comparator output off of this command: clear @p bow 0 0 I confirmed that for some reason it is giving you a ghost item or thinking you have the item even after removing it.
I think that it is just a universal pathfinding issue, hence my link to the bug with zombies path finding.