if (count == 0 && !isLinkedHash) {
        contents = new ObjectCountLinkedHashMap<E>(contents);
        isLinkedHash = true;
        // to preserve insertion order through deletions, we have to switch to an actual linked
        // implementation at least for now, but this should be a super rare case
      } else if (buildInvoked) {
        contents = new ObjectCountHashMap<E>(contents);

   * multiset1}, with repeated occurrences of the same element appearing consecutively.
   *
   * <p>Results are undefined if {@code multiset1} and {@code multiset2} are based on different
   * equivalence relations (as {@code HashMultiset} and {@code TreeMultiset} are).
   *
   * @since 14.0
   */
  public static <E extends @Nullable Object> Multiset<E> union(

 * in CVE number once it's available.)
 *
 * <p>Temporary files created by this stream may live in the local filesystem until either:
 *
 * <ul>
 *   <li>{@link #reset} is called (removing the data in this stream and deleting the file), or...
 *   <li>this stream (or, more precisely, its {@link #asByteSource} view) is finalized during
 *       garbage collection, <strong>AND</strong> this stream was not constructed with {@linkplain

   * that is not contained in {@code set1}.
   *
   * <p>Results are undefined if {@code set1} and {@code set2} are sets based on different
   * equivalence relations, for example if {@code set1} is a {@link HashSet} and {@code set2} is a
   * {@link TreeSet} or the {@link Map#keySet} of an {@code IdentityHashMap}.
   */
  public static <E extends @Nullable Object> SetView<E> union(

         *
         * TODO(cpovirk): Consider checking onlyOnRight.containsKey instead of right.containsKey.
         * That could change behavior if the input maps use different equivalence relations (and so
         * a key that appears once in `right` might appear multiple times in `left`). We don't
         * guarantee behavior in that case, anyway, and the current behavior is likely undesirable.