Defining "cachemode=aggressive" for a grouped collection leads to wrong
behaviour: when adding a HopObject to a grouped collection where the
appropriate groupnode doesn't already exist the HopObject won't be accessible
using collection.get(groupname).get(0) afterwards. The HopObject will only be
part of the collection if the application is flushed, restarted or another
HopObject is added to the same groupnode of the grouped collection.

To reproduce this behaviour put the following action into a global or root .js
file in Gobi (note that you need to modify the Page id in the first line of the
action):

Root.prototype._debug_action = function() {
   // change the page id to an existing one (eg. a skin)
   var pageId = 1173;

   var page = Page.getById(pageId);
   var type = "system:justatest";
   var direction = "out";
   if (req.data.action) {
      if (req.data.action == "add") {
         this.addLink(type, direction, page);
      } else if (req.data.action == "remove") {
         this.removeLink(type, direction, page);
      } else if (req.data.action == "flush") {
         app.clearCache();
      }
      res.redirect(this.href(req.action));
   } else {
      var groupObj = this.links_out.get(type);
      res.debug("groupobject: " + groupObj);
      if (groupObj != null) {
         res.debug("link: " + groupObj.get(String(pageId)));
      }
   }
   return;
};

Then, with a freshly started gobi application, do the following:
1) request the _debug action: the groupobject should be null
2) request the debug action with "?action=add" as argument: the groupobject
will still be null, which is wrong
3) request the debug aciton with "?action=flush" and both groupobject and the
added link should be visible
4) from now on adding/removing will work, because the groupnode
"system:justatest" already exists. however, if the groupnode is empty and the
application is restarted or flushed, the wrong behaviour appears again.