better APIs would be best solved by converting everything (users, comments, terms) to nodes.

Let's clarify the problem and look at the various options folks have taken or mapped out. Currently we have various different object types (nodes, users, terms, etc.), each with their own distinct APIs. Of these, nodes are most fully developed and have various properties and features (an access system, revisions, etc.) not available to other objects. Problems: a. Difficulties, duplication, barriers, etc. introduced by having distinct APIs and custom methods for each object type. b. Non-nodes are second-class objects, lacking much of the powerful node APIs. Potential solutions: 1. Parallel implementations. Create parallel implementations for other object types, giving them the functionality that nodes have. E.g., a taxonomy access system similar to the existing node_access one. 2. A node type for every object type, a node for every object. Create special node types to extend other objects, e.g., a 'user' (or user profile) node type, enabling non-node objects to receive node properties. The various node profile approaches fall into this category. 3. Everything's a node. Make everything a node, with specific object types (e.g., users) extending the node object. 4. Generalize node APIs. Take a lot of what currently is node-specific and generalize it so that it can be applied to any object type. E.g., rather than the node access system, an access system for any object type. A potential example to work from here is the search indexing API, which, while implemented only for nodes in core, nonetheless tracks a search 'type' that could be any object type. 5. New base object type. In addition to 4, introduce a new minimal base object type that all object types (nodes included) extend. Of these options: 1 and 2 have often been tried and, I think, most developers would agree they are at best only stop-gap solutions. 1 doesn't address problem a (difficulties, duplication, etc.). 2 introduces various problems of synchronizing, automating, etc. 3, everything's a node, is understandably attractive but has limitations that have been pointed out: nodes come with a lot that may or may not be applicable to other object types. Which in my view leaves us with 4 and 5 plus any other approaches creative minds may add to the list. Henrique Recidive and I worked with approaches 4 and 5 in sketching out ideas for D7 data APIs in "Data APIs for Drupal 7 and web services support", http://groups.drupal.org/node/6767 and "Active Records, a possible approach for consistent Data APIs", http://groups.drupal.org/node/6772.