For cross-plugin-compatibility i suggest adding a way for plugins to know if and why PlayerMoveEvent.setTo has been called.

Suggested changes:

• Add an enum like PlayerMoveEvent.DestinationChangeReason .
• Add setTo(Location, DestinationChangeReason) and a getDestinationChangeReason() to PlayerMoveEvent, also implicitly set the reason with the existing constructors/methods.
• Initial enum values should be: NOT_CHANGED (default), FEATURE (plugins use this to indicate that the programmer read the tbd javadocs, e.g. for a portal thing), SECURITY (important things), UNSPECIFIED (for using the setTo(Location)).
• (reason should not be null).

Summary of reasons why to have this:

• Plugins can detect changes to the event in an efficient way.
• Security plugins can set back with other plugins noticing the importance . Cancelling + scheduling a teleport would be possible but leaves quite a gap.
• Plugins can skip processing on SECURITY set-backs.
• Simplicity: No changes to obc/nms required, so far.

Spin-off:

• We could and probably should be having a teleport reason 'SECURITY' as well and use that one instead of 'PLUGIN' with this kind of set-back. This way other plugins can react towards security set backs in general, e.g. to force the player to redo the entire jumping puzzle. This would require obc/nms changes to inject/handle the new teleport reason.

(The Spigot version set for the ticket has been chosen at random.)