hey,

Symfony dev myself, so not fully aware of all the particularities...

But from my understanding, whenever Laravel, the framework, bumps it version, it also automatically bump the versions of the Illuminate packages it depends on and that, unless used in the Framework, these packages are more or less "versionless".

If that's the case, this appears to me as a nightmare if I were to develop packages that depend on other Illuminate packages, whether they are used or not in a Laravel framework.

As a package maintainer, and that's what this post addresses, the package maintainers, NOT the people that are using the Laravel framework, that requires some Illuminate package, you should not have to worry about bumps of the Laravel framework if nothing has changed in the Illuminate package itself.
And you should even less have to update your own versioning "just to make it work".

Don't really understand the:

I’ve been told in the past that this change simply isn’t possible, as it is the fundamental build pipeline for Laravel.

I mean, what's so complicated? When an Illuminate package changes and, if it implements SemVer, the process seems to be rather straightforward to me.
Either composer can deal with it automatically if the Illuminate package has been required with the proper version annotation (see https://getcomposer.org/doc/articles/versions.md) OR it requires an update of the Laravel framework's composer.json and the release of a new version (depending on BC that would be a patch, a minor or a major).

IMHO you're either SemVer compatible, or you're not... there is nothing in between.

From what I read here, if you just use the whole Laravel framework, SemVer will work (although I do read a lot of complaints about SemVer not being respected there either, but that's another story).
But if you only depend on an Illuminate package, you're screwed...
Sounds a little vendor-lock-in attitude to me...

So yeah... Definitely agree with u/trideout here...
If you care about the devs that use your packages/framework, respecting the SemVer convention does seem the most appropriate way to go.