I seem to remember Dries introducing a hack into Drupal.org to handle a bug with submitting issues lately, whereproject_issue" was becoming "project".

node_get_module_name is supposed to return the name of the module that defines the node type of the given node. This was not so in previous Drupals. Instead of this, it returned everything before the first dash, if there was no dash, it returned the whole node type. As the docs says "to prevent namespace conflicts, each node type defined by a module should be prefixed by the name of the module and a dash." this behaviour should be correct and works with, for example, flexinode well. But project module used underscore instead of a dash. This is the bug actually with which node_get_module_name was unable to cope. So project_issue was returned as module name instead of project. But now node_get_module_name is refactored to be what its description says. So, node_get_module_name ('project_issue') is by definition 'project', in the old version it returned 'project_issue" but that's not a bug it's just not "solid" code (ie it can not cope well with buggy data thrown at it). The mere usage of 'project_issue' in itself is a bug. All that being said, I can only hope that this will help those with knowledge of project module to come to a real fix. For example, moving issue.inc to a full-fledged project_issue.module for which 'project_issue' is a proper node type name... Another question arises: how well other Drupal core functions can handle garbage thrown at them? The other day quuxo pointed me out that if there is an entity in a permission name, then things won't work. I looked at user_admin_perm() and found that's true 'cos permission names are not collected before storage from modules but are used from $edit and there it is decoded by the browser. OK, this is just another very minor bug but somewhat I feel a rhyme in these two. Have anyone tried to shower insanse, non-API abiding, whatever data to poor Drupal functions? Regards NK