Spiral is a cycling waterfall. Thats the definition of spiral. That's what Boehm and other proposed when they invented it.
Even in each Spiral or Agile cycle, there are still step-by-step tasks/objectives that need to be finished...
Mostly true.
Is the main difference the introduction of a feedback loop into the process of development earlier on and throughout the process.
Yes.
is there a fundamental difference in the actual step-by-step completion of a task?
The feedback loop is the fundamental difference.
Waterfall demands Big Requirements Up Front (BRUF). It demands Big Design Up Front (BDUF) before any real coding can begin.
Spiral and Agile methods relaxe this demand.
like it's really just compressing and iterating
Don't make it sound so minor. It's not a little tweak. It's a fundamental change in the volume of requirements (and design) and how those requirements (or design) are used.
In waterfall, you can't really start without all the requirements. In many cases, this is an intellectual impossibility. It's hard to visualize all the ramifications of a new way of doing business and new software to empower that new way of doing business.
In Spiral or Agile, you don't have all the information. You have enough to get started.
Many folks want "Spiral" to be "Waterfall". They want a defined schedule based on a complete understanding. In order to stop that foolishness, many folks try not to use the "Spiral" word because it doesn't encourage getting started and delivering software right now with incomplete requirements.
It sounds like you are describing what Steve McConnell called Waterfall with Subprojects. In this methodology, you waterfall through conceptualization, requirements engineering, and architectural design. Then, for every major component, you then proceed through a detailed design, coding, and testing phase. At the end, you integrate the components in a system testing phase.
Typically, this is done by multiple teams at the same time, each working on a separate component. However, because you were working alone, it probably resembled a more iterative approach. The key difference between Waterfall with Subprojects and a true iterative approach is when you do the integration. In Waterfall with Subprojects, it comes at the completion of all subprojects. With a truly iterative approach, it happens continuously and you are fully integrated at the end of every iteration.
Best Answer
Definitions will vary so I doubt you will get a conclusive answer to this question.
Having said that, the most obvious potential difference I see is how the iterations relate to your high level design / architecture: