Reminder: the real definitions for HTTP methods are those published in the specifications that are registered with IANA.
In the case of PUT, the real definitions are in RFC 7231.
How do I correctly interpret that? That PUT must be idempotent?
The semantics are idempotent.
An important element of the REST architectural style is the uniform interface constraint; roughly: everybody understands all requests and responses the same way.
That means that we can stick a general purpose cache in front of a web server, and everything "just works" -- we all use messages the same way, so the cache can do intelligent things with requests. Everybody understands messages the same way, so we get inter-op "for free".
Because GET and PUT requests have idempotent semantics, duplicate copies of the same request mean the same thing. One useful consequence of that is we can automatically retry those requests if the response is lost - a very useful property when the message transport is unreliable.
But it doesn't mean that the request handler MUST handle the request in an idempotent way. What it means is that the implementation is responsible for any loss of property caused by the fact that the implementation doesn't respect the semantics of the request. See Fielding 2002.
If a PUT method is returning a different output for the same input that should mean it is not correctly implemented and therefore it is a bug?
Not necessarily: idempotent constrains the semantics of the request, not the mapping of which response goes with which request.
