Possible number of Sprint Reviews per Sprint

Shouldn't they be giving their feedback about any new work or rework to the Product Owner, who would then choose whether or not to incorporate it in the Product Backlog?

Remember that the key output of a Sprint Review is a Product Backlog that is up to date.

Also, bear in mind that there's nothing to stop a team and its stakeholders from collaborating and reviewing work continually during a Sprint.

There's one Sprint Review per Sprint, but that doesn't mean that the team - the Product Owner, the Development Team, or a combination of two - can't seek or accept feedback outside of the Sprint Review. There's nothing stopping communication between the Scrum Team and stakeholders about the doneness of work, targets and delivery dates, the ordering of the Product Backlog, the state of the marketplace, or budget at any point in time.

One thing to consider is that if you have Sprints that are one month long, perhaps that is too long to wait to have a formal synchronization point between the Scrum Team and stakeholders. Synchronization is one of the key points of the Sprint Review, and the frequency of necessary synchronization is a driving factor behind Sprint cadence. Perhaps shorter but more frequent Sprint Reviews would be beneficial for both the team and the stakeholders to help ensure that everyone is satisfied with the work being done.

@Ian Mitchell and @Thomas Owens covered most of what I would say but I do want to expand on something that each of them said. 

Also, bear in mind that there's nothing to stop a team and its stakeholders from collaborating and reviewing work continually during a Sprint.

My opinion is that if there isn't continuous collaboration you are losing a large part of the benefit of agile practices. Empirisicm is the basis of any agile practice.  Do something based upon the information that you have now, inspect what you did based on new information, adapt what was done, repeat.  Scrum's Sprint Review is intended to provide an event for this to occur but in other practices that event does not exist and is a continually ongoing activity. 

One thing to consider is that if you have Sprints that are one month long, perhaps that is too long to wait to have a formal synchronization point between the Scrum Team and stakeholders.

This is from the Scrum Guide section that describes the Sprint. Emphasis added by me

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Since you have identified a possible need for more reviews, maybe you have also identified an opportunity to shorten your sprint cycle.

Encourage the Team to Demo to StakeHolders throughout the Sprint i.e. multiple short Demos, even Demo work that is not fully complete.

They will get their feedback here and this will affect the Backlog.

I see this as the best use of StakeHolders with the Team in terms of interaction.

Hi Zoran Vasiljevic,

[1] There is only one formal sprint review per sprint. Either we need to consider reducing the sprint time box.

[2] Development team discussing and presenting the intermediate development frequently with Stakeholders and Product Owner is quite possible if the stakeholders and Product Owner is available frequently between the sprint. But this can not be call as sprint review. There is only one sprint review per sprint.

Reference: 

https://www.scrum.org/resources/what-is-a-sprint-review

Thanks.