Actually, it can be interpreted in 3 ways:
1. ...responsible for maximizing the value of product and maximizing the work
2. ... responsible for maximizing the value product and responsible for the work
3. ... maximizing the value of product and value of work
Anyway, it should be fixed.
I would put it: "The Product Owner is responsible for maximising the value of the product and the value of the work of the development team."
But it suggests that these are 2 different values (and in fact it's one value of product created with this work).
in Polish version there is no "only". Just "SM enforces that Development team attend Daily Scrum".
In team distributed among many timezones it might be even 24 h
Polish translation has "selected elements of Product Backlog" there. This is what authors might mean.
I guess this is mainly the idea of Scrum Primer. Scrum Guide is rather a definition and examples could make more problems than help
burn-downs are mentioned, but these are supporting methods, not part of Scrum. Scrum Guide should be kept as simple and short as possible, so I think that's enough
For some supporting Scrum methods I would suggest to see Scrum Primer or some books about Scrum.
That's a good idea ;) BTW, some effects of retrospectives could also be treated as even less formal agreements.
No one should be forced to use 100% accurate Scrum. You can always adapt it (Scrum-but), use other method (Kan-ban) or mix Scrum with something else (Scrum-ban). Scrum is just the way some people (like Ken Schwaber) suggest to do it. It's generally good, but in some cases you can adapt it. Scrum-buts shouldn't be called Scrums, but it doesn't mean they're bad.
If you write in Scrum Guide that all of the Scrum practices are changeable you describe in fact a do-what-you-think-is-right method. We don't really need a word for that...
That's why I see no problem in current situation - different organizations suggest different methods and call it with different names. And people use them as they want.
I still prefer the diagram from Scrum Primer...
There is already PB Refinement mentioned in Scrum Guide (page 13). I don't see a point in making an event of that - many teams work without such an event and still it's great Scrum.
However, Backlog Refinement workshop could be mentioned as an example of Backlog Refinement implementation.