YDS: How Should a Scrum Team Handle SPIKES?

That's a great thought, but help with this, should we have any product backlog item or user story to show someone is working on identifying an approach or work?

Sorry put this comment in the wrong place

I see your arguments but I am not sure that you have solved any problems by "dropping spikes". You re still going to do some work to either validate a user need OR decide on your options for solving that need. So you are still doing something. Now this can be done as part of the overall user story (possibly as a task within the story or just as some initial work) but it probably means that your story will be quite big and not fit a standard dev sprint. A spike is a way to manage (and remember this is the team managing itself) some work that won't directly deliver a business benefit within the sprint. It is not about gaining permission, but rather clarifying what needs to be done and what you are trying to find out.
We use spikes as ways to investigate large problems and solutions that need some high level thinking and that probably will affect several stories or a whole epic. We have a clear goal for the spike. We have some criteria that tells us when we have done enough work and have met our goal. Mostly we do this by defining hypothesis/experiments that can be validated or not but sometimes this is not relevant.
We can then prioritise spikes against all the more direct value stories we have in the backlog (with our PO). We usually estimate the work but realise that estimates are difficult for these type of items. Sometimes we timebox the work so as to not let the items take too much capacity within a single sprint. You also could reduce your sprint capacity but it amounts to the same thing.
We also try (although sometimes this can be difficult) to insist that the spike not only does some learning but actually has a tangible and reviewable output - such as a simple prototype of one sort or another. This then causes us to get into the problem or solution options and try things out to learn more.
This makes all our work visible, transparent, self managed/organised by the team, collaborative with the PO and have clear goals and limits.
Not sure how just dropping spikes can provide all this - unless they remain as part of the story as logical or physical tasks (which is what a spike is really) and you use a Kanban approach with different columns/states rather than iterations/sprints.
By definition then, a spike isn't a Scrum anti-pattern but you could select a different non-iterative approach to deliver this (e.g. Kanban) without splitting out a spike item.

Turn the SPIKES into Hackathons