In fact the OptionBuilder code is at best serially re-usable.
Even then, the second thread would need to ensure that reset() was called before starting to use the class, because the lack of synch. means that the static variables updated by one thread may not be published to the second thread - i.e. the second thread might see stale values even though the first thread called reset() as part of create(). And of course the threads would have to ensure that they took it in turns to use the class.
Note that Option is not thread-safe either (settters/getters not synch.), however if the Option instance is confined to a single thread it would be OK.
Many of the other classes are not thread-safe either, as they have mutable variables that aren't volatile or synch.
But if confined to a thread, they would be OK.
Unless the documentation says otherwise, it's not safe to assume that a lbrary is thread-safe.
But I agree that the OptionBuilder is a particular problem.
It could be fixed by using ThreadLocal for all the static variables. But is it worth the effort?