A third-party widget arrives with jQuery 1.7 bundled into its own script tag, the application is on 1.11, and whichever loads second owns window.jQuery — so one of the two sets of plugins is now attached to an object nobody is calling. noConflict is normally described as the fix for $ colliding with Prototype, which was its original purpose. The argument it takes is the part that matters here.
<script src="/vendor/widget/jquery-1.7.2.min.js"></script>
<script src="/vendor/widget/widget.js"></script>
<script>
// true: hand back BOTH $ and jQuery to whatever held them before,
// and return this copy so the widget can still be reached
var widgetJQuery = jQuery.noConflict(true);
</script>
<script src="/assets/js/jquery-1.11.1.min.js"></script>
<script src="/assets/js/app.js"></script>noConflict() with no argument restores only $; noConflict(true) restores jQuery as well and returns the instance, which is the only way to keep two complete copies on a page without one shadowing the other. The order is load-bearing: the copy has to be released after its own plugins have registered against it, because a plugin is a property on that specific jQuery.fn and does not travel. What it costs is that the two copies share nothing at all — separate data stores and separate event registries, so .trigger() on one is not heard by a handler bound with the other, and a single element can carry two independent sets of handlers. It is a way to survive somebody else’s release schedule, not a way to live.