My apologies for my slowness here; I've been quite busy, and haven't had time to review your PRs as promptly as I'd wish.

I can not foresee if people depended in weird ways on behavior that, to me, is a bug.

We'll just ship a major release, and people can deal with any incompatibilities.

An alternative I am considering is to strip down some of the features and create a new plugin that is more focussed on matching @import as it works in browsers.

Can you elaborate on this further?

An alternative I am considering is to strip down some of the features and create a new plugin that is more focussed on matching @import as it works in browsers.

Can you elaborate on this further?

This package also supports a few non-standard features.

• first import over all imports with skipDuplicates: true
• imports of npm packages

I personally tend to favor standard/specification defined behavior when creating and updating packages like these.

But I want to be respectful of all current users.
I don't want to steer this package into an unexpected direction.

Having two packages, each with a different focus can be a good alternative.
I don't mind creating a second package if this is best overal for users.

As far as I can tell these changes aren't breaking except for extreme edge cases, but I try to be mindful of my blindspots.