Is this always equivalent, since it seems to be working in reverse?

This basically gets fig.canvas.manager.num with the provision that each of these can be None. If this num is not registered in the figs dict, destroy will catch that as it first checks cls.has_fignum(num).
It's true that this may cause problems if two managers share the same num, but then the num->manager mapping is already invalid (set_active will already have overwritten the entry in the dict) so I'm not too worried about that.

I find the whole docstring a bit unclear. It seems to assume prior knowledge on figures, figure managers and their relation. Would this be a more complete description?

    Singleton to maintain the relation between figures and their managers, and
    keep track of and "active" figure and manager.

    When created via pyplot, a figure is associated with its own figure
    manager, that handles the interaction between the figure and the backend.

    This association is established via a unique identifier, called
    *figure number* or *manager number*. While figure numbers are often actual
    numbers, they can actually be any hashable value. The number is attached
    to the figure via the `.Figure.number` attribute; and it's mapped to a
    manager in the `.Gcf.figs` dictionary.

    This class is never instantiated; it consists of an `OrderedDict` mapping
    figure/manager numbers to managers, and a set of class methods that
    manipulate this `OrderedDict`.

Actually the number is an attribute of the manager (which is itself an attribute of the canvas), but other than that, looks good. Will incorporate a slightly edited version.

Pushed edited version. (Note that the identifier does not create the association, it's just used for bookkeeping.)