"J.P." writes: > If that's a realistic concern, perhaps you should consider keeping the > password param in its original position for the sake of compatibility. Recent discussions have left me with the impression that at least one consequential voice may be harboring reservations about the proposed interface change to `erc-nickserv-identify'. I'd like to offer some thoughts towards salvaging (at a minimum) the "prompting as a fallback" portion of this patch, which I feel may be helpful to new users. As a side note, the few changes that appear motivated mostly by promoting a separation of concerns seem at worst benign and otherwise potentially beneficial beyond maintenance matters (IMO). For example, adding a helper, like the proposed `erc-nickserv-send-identify', to encapsulate the actual request-making may improve this module's utility as a traditional library. (A few bots may even appreciate that.) Regarding the perceived minor bone of contention, my instincts favor the bold move, as usual. But that's contingent on all things being equal, which they likely aren't here (because passwords), meaning progressive attitudes may have to take a back seat. So as a compromise, how about an ugly chimera like the one in the attached example?