Возможность 1 не соответствует действительности. Для метода экземпляра было бы настолько необычно вызывать проблемы для других экземпляров, что это было бы четко задокументировано (не только с помощью указания, указывающего на это, но и с некоторым обоснованием, поскольку это, как правило, является признаком очень плохого кодирования, поэтому, если на это была веская причина, это будет указано).
Возможность 3 не соответствует действительности, поскольку они только что задокументировали поведение потоков.
Возможность 2 частично имеет место. Тем не менее, взаимодействие также может происходить с одним потоком, вызывающим Add, а другой - с другим методом, не поддерживающим поток.
Большинство изменяемых классов, предоставляемых платформой, являются поточно-безопасными для статических членов и не поточно-безопасными для методов экземпляра. Это по уважительной причине.
Если статический метод не является поточно-ориентированным, очень трудно выполнять вызовы этого метода в поточно-ориентированном режиме, особенно если класс может использоваться разными уровнями кода, написанными разными людьми. Это делает усилия, направленные на то, чтобы сделать такие методы потокобезопасными, почти всегда оправданными. Большинство таких элементов также относительно легко сделать потокобезопасными в любом случае (если избегать наличия изменяемого статического состояния, что всегда полезно избегать).
Значительное использование отдельных объектов будет осуществляться одним потоком за раз, без возможности доступа к нему другого потока. Это делает трудным обеспечение правильности, с риском тупика, если он пойдет не так, и накладные расходы, накладываемые на производительность, трудно оправдать. Для человека, использующего класс, относительно также легко гарантировать, что экземпляр, который используется несколькими потоками, используется в поточно-безопасном режиме.
Там делается большой акцент на «относительно», поскольку написание многопоточного кода не всегда легко. Иногда это довольно просто (неизменяемые классы занимают немного времени, чтобы сделать не поточнобезопасным!), Но чаще это очень сложно (отсюда много вопросов по этой теме здесь и в других местах).
И все же именно поэтому бремя должно быть наложено на пользователя в таких случаях. Сделать такой класс полностью потокобезопасным настолько сложно (а иногда и доказуемо невозможно), что результаты будут неприемлемы для большинства пользователей, которые являются людьми, которые в лучшем положении могут судить о том, какая защита необходима в данном случае.