It also needs to be mentioned in the API change note as if you register a method into it currently we will keep a hard-ref that keeps that object alive, the CallbackRegistry will only keep a weakref and if you otherwise let the object get gc'd your callback will go away. I don't think we need a deprecation path on that.

On the other hand, to channel @anntzer he will say we should always keep a hard-ref and keep objects alive (I am skeptical of this).

I added an API change note.

(I'm not going to fight over this, at least being consistent within the library is good too.)

Actually I missed two points here:

• We could have kept the old strong refs behavior by using the wrap-in-lambda trick (Prevent GC of animations and widgets still in use. #16221/Use CallbackRegistry for {Artist,Collection}.add_callback. #18912).
• If you connect the same function twice to a CallbackRegistry, the second (and later) connections are silently dropped per

  matplotlib/lib/matplotlib/cbook/__init__.py

  Lines 180 to 181 in ce29648

  	if proxy in self._func_cid_map[s]:
  	return self._func_cid_map[s][proxy]

  which is perhaps even more likely to be a source of API breakage than the strong/weakref difference. Again wrapping in lambdas solves the issue (because each lambda is effectively unique, and equality of lambdas doesn't look into their implementation), but at least this should be noted in the API changes note. (This can easily be checked by e.g. comparing for _ in range(2): gcf().canvas.mpl_connect("key_press_event", print) and for _ in range(2): gcf().canvas.mpl_connect("key_press_event", lambda e: print(e)).)

May be nice to decide on this before 3.4 gets released @QuLogic @tacaswell @timhoffm