are we sure nobody is putting a string value now, and relying on it being a noop?

What if it's an empty string?

Right now any value other than false (including an empty string) just does normal "browser" field resolution.

We've never supported any value other than false for this argument and since this is an additive change, I'd argue it could be released in a minor version. But I'm also fine with releasing it in a major version to be extra safe, though I think it's a bit overkill.

Sorry, that was two questions :-) you answered the first, but not the second - after this PR, should an empty string be allowed?

The simplest rule would be: if the type is string, then we look for that key in package.json and apply the "browser" field spec.

So, then an empty string would look for an empty string key in package.json.

But it's also likely to be a bug, so also I'm okay with throwing an exception in this case.