Object of class stdClass could not be converted to string

Yes I was. Sorry, I didn't spot this. I wonder if it might be better if you don't allow the $user object to be passed in, but raise a clearer watchdog error instead, such as "boost_set_cookie now requires a $uid". Otherwise people like me will never fix their code!

The recent beta of Flag module allows flags (eg "bookmark this page") to be set for anonymous visitors. The flags are stored in the session - see http://drupal.org/node/271582 - and so can be different for each anonymous visitor. Clicking on a flag link will change the text of the flag link from "Flag this ..." to "Unflag this ...", though the URL remains the same. However, this does not work nicely with boost, since of course boost serves the same cached page to each anonymous visitor. There are a couple of ways round this:

1) Do not cache any pages with a flag/unflag link on them. But this is no use for sites which have the links on most pages.

2) When a flag is set, set the boost cookie so that that particular user sees the uncached pages from then on, and so will see pages with the "Unflag this" link:

// Implementation of hook_flag, called when a flag is set/unset
function mymodule_flag($action, $flag, $content_id, $account) {
// set the boost cookie to ensure that cached pages are not served, and
// the user sees pages with the flag set/unset as appropriate
  global $user;
  boost_set_cookie($user->uid);
}

// Implementation of hook_boost_is_cacheable().  Make sure
// that pages with a flag set are never cached
function mymodule_boost_is_cacheable($path){
  // get node id from path
  $path = drupal_get_normal_path($path);
  $args = explode('/', $path);
  if ($args[0] == 'node') {
    $nid = $args[1];
    $flag = flag_get_flag('bookmarks');
    if($flag->is_flagged($nid)){
      return FALSE;
    }
  }
  return TRUE;
}

This works for me, though it may need some refining. It does mean that the cache is disabled for all pages for any visitors who set a flag on even one page, but I am happy with that at the moment.

I suppose this sort of approach might help with anonymous shopping carts, and modules such as fivestar.

Edit: Well, this *was* working, but I've noticed that your new code now removes the cookie in boost_init if $user->uid is 0. This means that the cookie can never remain set for anonymous users, which is a great pity. There is no other sensible way to ensure that particular anonymous users can bypass the cache. Is there another way of signalling that the cookie should be removed by boost_init on the next pass, perhaps by setting the value of the cookie to something like "remove" (i.e. non-numeric)? That way, its value could be '0' if the user is anonymous, and the cookie could stay in place.