Hi David,

First; I don't think this is a bug. The INode/Node combination works perfectly well, and as you noticed it is placed in another namespace than the old nodeFactory, which means old code won't break since the old nodeFactory is still in the assemblies.

Working with the new NodeFactory I would write your second example like this:

Node n = new Node(1234);
INode p = n.Parent;
// or
Node p = (Node) n.Parent;

Depending on what you need exactly. More often than not, an INode is perfectly adequate, and I would stick to the first parent declaration.

Checking with Reflector reveals the following methods and properties on INode

public interface INode
{
    // Methods
    DataTable ChildrenAsTable();
    DataTable ChildrenAsTable(string nodeTypeAliasFilter);
    IProperty GetProperty(string Alias);

    // Properties
    List<INode> ChildrenAsList { get; }
    DateTime CreateDate { get; }
    int CreatorID { get; }
    string CreatorName { get; }
    int Id { get; }
    int Level { get; }
    string Name { get; }
    string NiceUrl { get; }
    string NodeTypeAlias { get; }
    INode Parent { get; }
    string Path { get; }
    List<IProperty> PropertiesAsList { get; }
    int SortOrder { get; }
    int template { get; }
    DateTime UpdateDate { get; }
    string Url { get; }
    string UrlName { get; }
    Guid Version { get; }
    int WriterID { get; }
    string WriterName { get; }
}

So as you see there's a lot of stuff available for you. I'm especially fond of the new ChildrenAsList property, which is very useful with Linq-2-objects, meaning you can easily do stuff like:

var node = new Node(1234);
var textPages = node.ChildreAsList.Where(c => c.NodeTypeAlias == "textPage");

Regards
Jesper Hauge