I said above that I could see underscore-prefixing the method name. I am now convinced. I also agree with @jaubourg on testing it, and have been letting this sit in the hopes that it could be rebased on top of #1060 (for consistency), but it looks like that may not happen.

As for the meat of the disagreement, I'm still with @dmethvin on wanting the definition in ajax.js.

> Question: where will this be documented? In the ajax module doc or the manipulation module doc? Elsewhere?

Realistically, it's probably best documented as a footnote on some manipulation summary page:

<em>Note: When new content containing script elements with the `src` attribute set gets connected to the `document`, jQuery attempts to synchronously fetch and evaluate the scripts by calling the ajax module's `jQuery._evalSrc`. If you are using a build without the ajax module, you will have to define this method yourself in order to prevent these DOM manipulations from throwing exceptions.</em>

> I fail to see how "punching in a hook" is worse that incanting a method out of thin air. If some functionality has to be provided to the manipulation module for it to properly function, how does it make sense to define the hook in another module?

Because that functionality is provided *by* the other module. This is a dependency upon ajax, and in that sense is no different from the use of `jQuery.css( elem, type, extra )` in [dimensions.js](https://github.com/jquery/jquery/blob/a918dc8aacb8461321c332f6f3b5756bdda5e8b2/src/dimensions.js#L34).

> How is a reference to getScriptSync buried inside domManip "better" than a reference to ajax inside a 5-line long _execScriptFromSrcHook? Don't you think the former will give the impression you have to have the default ajax implementation in order for domManip to function?

I don't think so. `Error: $.foo is not defined` suggests to me that I need to define `$.foo`. I most certainly *don't* want that to be `ajax`. Why make devs dig to find the specific method when we can let the browser's console do it for us *and* get a smaller library to boot?

> BTW, how is domManip relevant to someone implementing (or bridging with) another ajax implementation? Isn't a short method called _execScriptFromSrcHook with a simple call to ajax inside that much clearer than a getScriptSync that is nowhere to be found in the code?

No, because no one will know anything about the method until ey start inspecting our source code.

> None of this is advertised on the tin. The method is worthless as an ajax helper because it is *not* an ajax helper.

That's not entirely true. It is a way of bypassing some of the global ajax options that can make the module behave unpredictably, and if documented will certainly become the preferred method of synchronously executing script URLs (admittedly, probably not something we want to foster).

> What are the reasons that make you think the intent of this method is made clearer by defining it in the very module that will not be part of builds where said method needs to be provided?

In short, excluding ajax creates an unsatisfied dependency in certain narrow uses of `domManip`, the nature of which I want to be obvious (i.e., method not defined) and the scope of which I want to be small (i.e., method !== "ajax").