> I don't think we're looking for an overridable hook. We're trying to provide a flexible way for alternate ajax implementations to provide sync script evaluation by exposing an interface.

Quite the contrary I'm afraid.

We're doing all of this so that people can use whatever ajax solution they prefer without having the weight of the ajax module in their version of jQuery.

Let's consider doing so by asking implementations to expose a specific helper. We're talking about imposing the name and signature of a helper in that implementation. A helper this implementation will have to expose publicly and probably document. But that's supposing we're talking about a jQuery implementation in the first place.

Let's consider the alternative implementation is NOT a jQuery plugin but, say, library X (dojo, YUI, ...). At one point, I inject HTML with scripts in my DOM using jQuery and it complains: `jQuery.getScriptSync is not defined`. I search the documentation and find, in the ajax module section, the description of a helper with a note saying it's used internally by the manipulation module to execute script tags with a source found in injected HTML and has to be defined by any alternative ajax implementation (I tried to make the explanation as simple as I could but good luck having something that makes sense buried into the ajax doc).

Now, the solution is simple, in my app, I just add:
```js
jQuery.getScriptSync( url ) {
    X.request(...);
}
```

But look what happened here: I didn't "expose" a method on library's X interface (`getScriptSync` is not part of the interface of library X). I just defined a function on the jQuery object to change the behaviour of jQuery (not throwing an exception anymore and actually loading scripts). That's the very definition of an overridable hook, even if the default implementation is `undefined` (which I have a big big problem with).

> Since the interface we need is ajaxy, it seems most logical to put it in ajax.js.

You're asking yourself the wrong question. The actual question is: does using this new method outside of manipulation make any kind of sense? Absolutely, unequivocally: *NO*.

This method is specifically, narrowly, tailored for `domManip`. *This method has absolutely no value as a generic method used outside of the realms of manipulation*. Why on Earth we're so bent on putting it into the ajax module is a mystery to me (though I blame it on our the endless quest for bytes going very wrong).

It's a helper used internally by the manipulation module, not the ajax module and it belongs to `manipulation.js`. The fact it does an ajax request is irrelevant. As I said before, throwing an exception is an acceptable default implementation that doesn't do anything "ajaxy".

That's why we have modules that expose interfaces, so that one can use said methods rather than editing the module's source code to hack in their own function. Sadly, that's exactly the latter that is proposed here: let's put an internal method of `manipulation.js` in `ajax.js` because we want it exposed and it does something "ajaxy" anyway and we want things to fail when `ajax.js` is not in the build. Too bad this method doesn't use anyting internal to `ajax.js`, isn't used by anything inside of `ajax.js`, doesn't serve any generic purpose (this is *not* an ajax helper) and was formerly part of an undocumented internal function of another module entirely.

In conclusion:
* we do want an overridable hook not some interface constraint on alternate ajax implementations (it doesn't even make sense when talking about non jQuery centric solutions)
* this hook is extracted from an internal method of `manipulation.js` to be exposed so that it can be overriden to change the behaviour of said internal method. It is thus internal to `manipulation.js` and has nothing to do in `ajax.js`.