This project has the following goals:
 - Make the entire property sheet API model driven - 
  eliminate the dependancy on Node.Property, et. al.
  Currently PropertySheet has a hard dependancy on
  Node.Property, and PropertyPanel is model driven with
  an incidental dependancy on Node.Property.  This
  schism is responsible for a huge amount of code
  complexity in the PropertySheet package, and a 
  number of hacks.  A new implementation should be
  self consistent
 - Provide a lightweight property rendering infrastructure
  usable by components such as TreeTableView (and of 
  course PropertyPanel) 
 - Split the property infrastructure into two pieces - 
     - a property SPI library providing interfaces modeling
       properties and property containers
     - a property sheet implementation library with a 
       public API for property rendering, etc.  Providers
       of properties will not need to cart around a
       property sheet implementation if used outside
       NetBeans.
 - Eliminate the dependancy Looks has on Node.Property - 
   interfaces will need to be compatible with
   Node.Property/PropertySet such that they may
   implement these interfaces (no more performance
   killing model instances created to bridge Node.Property
   and the current PropertyModel, and no more hacks
   such as the ReusablePropertyModel in the new 
   PropertySheet code)
 - Provide a bridge to the existing property  
   sheet/property panel API and deprecate that API.
 - Allow objects to flexibly provide properties without
   needing to depend on Nodes

Open questions:
 - Is the PropertyEnv stuff even useful?  The hinting
mechanism FeatureDescriptor.getValue(String) should be
covered by the new interfaces.  In that case, the only
value it has is as an object specific to a single rendering
case that may be used to transmit values needed only in
that use case.  AFAIK nobody uses it in this capacity.

 - Would a Looks-like mechanism be good here for modifying
or suppressing properties?  This would eliminate the use
of FilterNode only for the purpose of altering the property
set of some nodes.

  AFAIK the only difference between nodes and properties
is that properties are leaves, and only one level of 
hierarchy is supported (PropertySet->Property).  It would
be relatively easy to preserve the semantic difference,
which is useful to programmers, but eliminate the 
implementation difference (with the exception of perhaps
a requirement to maintain the hierarchy limitations of 
properties).  Properties could be an alternative 
sub-hierarchy of a node provided by the look.  In this
case, Node.Property/Set need not implement the new property
interfaces, Looks could simply provide a compatibility
bridge.