Another widely observed reason for the wheel being reinvented every time is the case of the slight deviation.
Every need is unique and with every uniqueness, the pattern is re-interpreted and improvised to make it fit. The shift from deviant to non-compliant happens fast because every improvisation is seen as a work of greatness by the development team!

http://quince.infragistics.com – web/desktop patterns, interesting as a navigation system for pattern catalog
http://ui-patterns.com/patterns – web patterns repository – fixed set of patterns
http://uipatternfactory.com – web patterns repository – patterns are being added frequently
http://interface.fh-potsdam.de/infodesignpatterns/patterns.php – not for GUI design; it’s more for presentation of information

It’s not only a matter of publishing a list of patterns but also making them reachable to the consumers, as you said.
Thus, the publishers should not rely on the consumers looking for an exact term but instead opening the list of terms as in the web pages “keywords” meta tag.

If the users are allowed to enter the name of the concepts that led them to a particular pattern then a semantic network would build.

Another method is to publish mockups of already dome work with the contained artifacts linked to the pattern used in the solution.

On making standard: With OOP, even though folks were likely using some of them before without the patterns’ labels, the “standard” patterns were established with the watershed “Gang of Four” book and most has come off of that … it just happens that we already have a number of great references that don’t necessarily share the same language. If the authors of the existing libraries, along with the rest of us, could agree on some standard patterns, including names for them, it could help make tham way more accessible to many folks. We need some kind of common reference to work from, but does not require a central authorizing pattern body. Patterns that work should survive out there in the wild… but they do need to be documented by someone and given a name everyone can use to mean the same thing. Maybe B&A is a good hub to establish this?

On variants/deviation: Patterns help check for common solutions, i’s to dot, and t’s to cross. Instead of starting everything from scratch, a pattern encapsulates ideas and approaches to implementation. Yet the nuts and bolts of how a pattern is applied in context is even more important, and still requires insight on how the interact with the whole in each case. This is where variants are created and applied, and doesn’t mean that they are in conflict with “the official” pattern. Patterns are living documents based on well-understood behaviors and structures: they may stabilize as they mature, but as more insight about them is gained, they can still change and new ones can be found (or in-house libraries made to encapsulate the variants within the organization).

On using code: I think if standard, industry-wide UI Patterns can be aggreed on, the patterns themselves should remain in the domain of UI, and avoid references to code… having code would stretch them too far. The community could add examples of how to implement them in a web page or whatever, but the pattern itself should only be concerned with the actual front-end UI elements. I think the references Patrick mention already steer clear of code specifics.

http://quince.infragistics.com