The SemVer spec gives you a lot of flexibility. Nothing in the spec precludes your using the numbered scenario you describe in your original post. Your alternative suggestion is also valid, as far as SemVer is concerned. Both scenarios start out with the 0.y.z form, which is meant to be used for initial development leading up to 1.0.0. Any applied prerelease tags are mostly sugar, though they will factor into the sort order (1.0.0 > 0.1.0 > 0.1.0-otherPreleaseTag > 0.1.0-anyPreleaseTag).
4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
These are all legal SemVer version histories:
H1
0.1.0
0.1.1
0.2.0
0.2.1
1.0.0
H2
0.1.0
0.1.1
0.2.0
0.2.1
1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-beta.2
1.0.0
H3
0.1.0
0.1.1
0.2.0
0.2.1
1.0.0-alpha
1.0.1-alpha
1.0.2-beta
1.0.3-beta
1.0.3
SemVer supports an endless variety of develop/release patterns. The key is that the spec applies the same exact semantic meaning to all prerelease tags.
9. …A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
You just need to focus on the precedence rules, which define the sort order that is applied with deciding a match to consumer intent, from the available versions.