I think that in fact, many packages simply don’t care about their thread safety status. One reason for that might be that not many users of the package actually use it in a multi-threaded context, but it may simply be that the author genuinely isn’t interested.
Free-threading is sparking people’s interest in multi-threading, but that’s often library consumers. So I see library authors getting increased pressure from outside to care about thread safety, but they may well still have no personal interest in the matter.
I disagree. They should be fixed if the library author cares about thread safety, and if the runtime penalty for single-threaded code is sufficiently low that the library author is willing to accept it in return for thread safety (although if they deliberately choose not to make that trade-off, they should document that fact, of course).
Maybe you view the above as obvious, but I’ve seen enough well-meaning users raising issues and insisting that “you must fix X”, pointing to statements like your post as justification. The reality is that (as has been said elsewhere in this thread) most pure Python libraries are no more or less thead safe with free threading than they were with the GIL. So if they have survived this long, free threading shouldn’t make any significant difference unless the library author wants it to.