If it's only for the top level couldn't you just do this already?

var params = $.param((function(){
  var obj = {};
  // Dynamically build obj 
  return obj;
})());

You can, and your example is essentially how I am handling it now. But I guess for the same reason you wouldn't want to do:

var params = $.param({
  a: (function(){ return 1; })(),
  b: (function(){ return 2; })(),
  c: (function(){ return 3; })()
});

..more key strokes, more bytes, uglier code. Probably the most relevant reason (for me) is dealing with ambiguous variables.

Consider the following example (which happens frequently in my world):

function Widget (options) {
  this.url = options.url;
  this.params = options.params; // Plain object -or method that returns object.
}

Widget.prototype.remoteFunction = function () {
  $.ajax({
    url: this.url,
    data: this.params // Could be object or method
  });
}

Simply invoking this.params would result in an error if an object was passed. So, I find myself adding abstraction:

data: typeof this.params === 'function' ? this.params() : this.params;

(might not seem like much, but this is repeated a few dozen times in each of my projects)

This seems to break the model of library (most abstract) to plugin (less abstract) to implementation (most defined). And, in my opinion, the most natural place for an ambiguous entry point would be the library.

On a lesser note:

function getParams () {
  return {};
}
$.ajax({ url: 'abc.php', data: getParams }); // Seems more intuitive than
$.ajax({ url: 'abc.php', data: getParams() });

Allowing a function argument would result in the same for both examples, but currently only the latter would work.

I'm opposed to expanding the input signature in this way, and with @dmethvin on valuing consistency between jQuery.param and JSON.stringify (i.e., if we call anything it should be as toJSON serialization methods). Come to think of it, I wonder how much of this we can deprecate in the 3.x release cycle.

I agree with Dave and Richard.