Proposed Solutions for Items not yet on Sprint Backlog

By contrasting your team’s implementation with the Scrum Guide, what observations would you make yourself? How do the “events” you describe compare, and the roles you mention? What about rules - should items be locked-in, for example? Where there are discrepancies, what problem are they meant to solve?

Actually, this is not the way I've known Agile and Scrum. I have just recently joined a company as a Scrum Master, and they have just implemented this process a few weeks or months before I started.

It's good that collaborations, whichever you want to call it, happens before the Sprint Planning. However, I don't believe that the development team should think of specific proposed solutions (as in document the specific classes and methods they will be changing, or a detailed coding strategy to implement an item, or create test scripts that will be followed during manual testing) before the team decides to include on the sprint since priorities, requirements, clients needs and/or market can change. Creating detailed propose solutions and test cases for items not yet part of the sprint is not exactly aligned with the principle "Simplicity--the art of maximizing the amount of work not done--is essential".

I think you make a fair analysis, and it seems like you are in a position to make your own critical assessment. Perhaps the issue to be focused on is not so much the “violation” of Scrum’s pillars and agile principles, but whether or not Scrum is being implemented well.