In this specific case, it's a bug in an API of an internally-used library that other developers use.
If those other developers thought the behaviour to be a feature, it is likely they have used it and have build working software upon it. Fixing the bug will probably break their existing code, and they will blame you for this. This makes fixing the bug a trade-off, and you have to consider
is it really important to fix the bug, for example because there is a high risk of letting users of your API crash their applications in case the bug is not fixed? Or is this just about consistency of the API?
or is it more important to keep the existing software stable, and your library backwards-compatible?
The answer to the question is not always simple, you have to take the number of possible users of your API into account, the potential amount of work they will have to change their software, the amount of software which will break if you change your API, but also the risks of what might happen if you do not fix the API.
Just because you document the bugfix change in a "list of breaking changes in your next major release" does not make your customers happy - if you do this, there should be at least some bullet proof reasoning why you could not let the API as it was before. Often keeping backwards compatibility is more important than fixing a bug. So fix it only if you can estimate the impact on your user base and their software and you are sure you are not going to produce unreasonable efforts for them when they try to update to your latest library release. And if you do not have enough information to make a good estimate on this, it will probably be better not to change the behaviour.
(And yes, if you are going to make an API change which is not backwards compatible, your version numbers must express this clearly, does not matter if you name it a "bugfix" or not).