Questions about the ReactiveController pattern promoted and used by Lit

Question

Please find below three different ways of implementing some ReactiveController with Lit.
A typical ReactiveController implementation with Lit looks like Pattern 1.
Please be aware that in Pattern 2 and Pattern 3 there's no implements ReactiveController as all methods of interface ReactiveController are optional by design.
Pattern 3 uses a factory function to create objects of type typeof SomeController. This has for example the advantage that some day in future, depending on the arguments different subtypes of SomeController may be returned, which is not possible with Pattern 1 and Pattern 2.

Questions:

1. Are Pattern 2 and Pattern 3 in some way kinda violating Lit's ReactiveController model/idea?

2. In Pattern 1: Are there real-world use cases where instances of SomeController will be passed to some addController method a second time? If no, what do I really need those public methods hostConnected and hostDisconnected for and why not just always use Pattern 2 or Pattern 3 instead (except for "matter of taste" and maybe code readability)?

// Pattern 1

export class SomeController implements ReactiveController {
  ....

  constructor(host: ReactiveControllerHost, ...) {
    ...
    host.addController(this);
    ...
  }
  
  hostConnected() {
    ...
  }

  hostDisconnected() {
    ...
  }

  ...
}

The exact same controller can be implemented in this way:

// Pattern 2

export class SomeController {
  ...

  constructor(host: ReactiveControllerHost, ....) {
    ....
    host.addController({
      hostConnected() {
        ...
      },

      hostDisconnected() {
        ...
      }
    });
  }

  ...
}

Also, using a factory function is possible:

// Pattern 3

export function getSomeController(...): typeof SomeController {
  return new SomeController(...);
}

// class SomeController class is local, will not be exported
class SomeController {
  ....

  constructor(host: ReactiveControllerHost, ....) {
    ...    
    host.addController({
      hostConnected() {
        ....
      },

      hostDisconnected() {
        ....
      }
    });
  }

  ...
}

Answer 1

I guess, it's due to the fact that the controllers implemented with pattern 2 and pattern 3 cannot be removed later by using host.removeController(...). So this is against the basic idea of addable and removable reactive controllers.