Product increment as input of the Sprint Planning

A product is developed incrementally.

There should be a "Done", releasable increment of the product. The Development Team should be able to inspect and adapt towards producing at least the next increment within the new sprint.

Without transparency about the most recent increment, how could a Development Team forecast what can be included in the next increment?

In addition to what Simon Mayer said, I can also think of an example to consider.

What do you do when you change your Definition of Done? Work that was previously done and incorporated into the Product Increment may not meet this definition. The team needs to consider the current state of the product to help guide their planning. Depending on the nature of these changes, the fact that some work is "undone" may cause the team to need to slow down, either to be more careful or to invest time and bring the work up to the current Definition of Done.

This is similar in nature to technical debt. Nearly all products have some level of technical debt. Things that were learned by doing the work, things left undone in favor of getting something in front of stakeholders for faster feedback, or simply a lack of knowledge of better ways to do things. Since the technical debt is inherent in the product, I would suggest that inspection of the product is the best way to determine the level of technical debt and the impact of this technical debt on the work planned during Sprint Planning.

What is the main reason for the latest product increment to be an entry?

Increments are cumulative. The planned increment must include all previous increments.