The Scrum Self-Organising Team Paradox
We know that if any of the core elements of scrum are missing, it ceases to be scrum. We also know that scrum teams are self organising and decide how best to accomplish their work.
What if the team decides to drop or fundamentally change a key component of scrum as they believe it will help them accomplish their work better?
From the perspective of someone who writes or marks the scrum.org assessments what would be acceptable response to this challenge?
A core value of agility is "individuals and interactions over processes and tools". I don't see any issues with a team deciding to make a fundamental change to one of Scrum's rules. If they do, however, they can no longer call what they do Scrum. This is a good thing that helps with communication - the word "Scrum" refers to a set of rules. If you are playing by a different set of rules, you should choose a new name for that set of rules. There's a difference between Scrum's immutability and the immutability of the processes and practices used by an organization.
Scrum is just one framework to enable organizations to be agile. If an organization feels that they can be agile without following the Scrum framework and still be successful, I think that is great. In reality many companies will borrow various techniques from a wide range of agile practices. Many companies using Scrum will adopt User Stories and Story Points, both of which come from Extreme Programming. Others will use some Kanban principles by implementing Work In Process (WIP) limits.
But you are correct that if you do not use the framework as described in the Scrum Guide, you will not be doing Scrum. But not all organizations are successful with Scrum.
What if the team decides to drop or fundamentally change a key component of scrum as they believe it will help them accomplish their work better?
Why not evidence this outcome, for the domain in which they operate, and thereby progress from belief to knowledge?
Fundamentally it's about getting valuable increments to Done. When teams deepen their knowledge and hopefully 'transcend' (Ri), then let them validate their belief. If it works, great (metrics are really helpful here)! If not, try something else. Iterative development applies to both the product AND the process.