You're right. And that is a hard problem.

At the beginning of the Agile movement, years before the Agile manifesto, they didn't know what they were doing, they only knew that they needed something stronger than what everyone was saying. So, they started to mix concepts.

So, they started doing Unit Tests, but instead of testing units of code, they started testing behaviors. But by then, testing behaviors was not a thing, so for them those were just unit tests. Furthermore, there were no XUnit libraries/runtimes by then, and in fact, they invented the Unit Test libraries and runtimes to do their "unit tests". And they called that unit tests because they hadn't a better name. When they realized that what they were doing was different, they started to shift from unit tests towards developer tests. But it was too late, the world had already started to call unit-tests to what they were doing. More than that, they also invented TDD, and they initially explained it as doing "unit tests", but their unit kind of tests, and they couldn't change it.

It wasn't until almost a decade later, in 2004, that Dan North and their colleagues realized that unit-test was a bad name (yes, because the developer test naming was almost lost in time), and they coined the behavior naming. And they succeed where their inventors failed. But they failed too, the waterfall QA concept world stole the concept, and they used it to just call tests written un gherkin and executing and e2e tests, for testing basically user interfaces and forgetting about the basic of testing one and only one behavior (most of those test fail if any other behavior fail, because have too many steps and require to activate many behaviors during its way).

So... that is how we end up in where we began, calling unit-tests the tests that test a unit of behavior.

And the idea is that the needs for a developer, and the needs for a QA are different, so their tests, and their tools.

But... once again, you're right that we need a better name. Because now, we have no name for that kind of test, and people get obsessed with implementation details of the test. And obsessing with implementation details is the wrong strategy when thinking about testing, and it is the strategy that has made TDD and testing so unpopular. And even counterproductive.