Expand API-based control over pane type configuration forms

Although implementations of the panels_content_types() hook allows the author considerable control over the way panels handles and displays its content_types/pane_types, there remain some aspects of the process that are inaccessible to external implementations of panels' API - at least, without some really awkward hook_form_alter() calls. Nobody likes that.

The expansions to the hook_panels_content_type API that I'm considering are of two different stripes, as I'm currently thinking about them:

1. Greater control over the appearance and default values of the content type configuration form itself. At present, the API wraps the calls to the content type add/edit callbacks in such a way that implementations of the hook are incapable of circumventing anything that appears by default in the form. Some callbacks do exist that can disable certain elements, but that system needs to be made more robust.
2. The provision of some more, slightly less 'standard' callbacks in the panels_content_types() hook that make common needs easier. The primary case I've got in mind right now is pane visibility: we often want to cause certain panes to be visible or invisible, depending on a set of circumstances only known at the time of the page request.

Examples involving $user are the easiest to grok: you want to restrict buddylist visibility in a profile only to friends of the $uid to whom the profile page belongs. By implementing the visibility callback, panels will know to check for & call any visibility callbacks whenever the render process is underway. Here's an example visibility function I originally wrote for og_panels, although it didn't make it in:

/**
 * Determine pane visibility based on pane settings and the user's group membership status
 *
 * @param string $op
 *   Pane visibility setting
 * @param int $nid
 *   The nid of the group being referenced
 * @return bool $visible
 *   Given the parameters passed in, indicates whether or not the pane should be rendered for that user
 */
function og_panels_contenttype_helper_visibility($op, $nid) {
  // use static variable to somewhat reduce queries on complex og_panels pages
  static $visible;
  if (!is_array($visible)) {
    $visible = array();
    $visible['all'] = TRUE;
  }
  if (!isset($visible[$op])) {
    global $user;
    $members = array();
    // @TODO this query currently excludes inactive group members, effectively placing them in the 'nonmember' grouping. Should this be changed?
    $sql = "SELECT u.uid AS uid, ogu.is_admin AS admin FROM {og_uid} ogu INNER JOIN {users} u ON ogu.uid = u.uid WHERE ogu.nid = %d AND ogu.is_active = 1 AND u.status = 1 ORDER BY ogu.created DESC";
    $result = db_query($sql, $nid);
    while ($account = db_fetch_array($result)) {
      $members[$account['uid']] = $account['admin']; 
    }
    $visible['member'] = in_array($user->uid, array_keys($members));
    $visible['nonmember'] = !$visible['member'];
    $visible['admin'] = $visible['member'] ? $members[$user->uid] : FALSE;
  }
  return $visible[$op];
}

Being that visibility is only relevant during the render process, it's crucial that visibility functions be as lightweight as possible. The above function accomplishes that by needing to make only a single query per page request - every one of the four possibilities for the $user making the page request is determined by that query, and the results are cached via static variables. However, visibility is only one of a number of #2-style API expansions I'd like to eventually see in operation, and suggestions are welcome.