On an implementation level, this makes sense. But on an interface level, I prefer individual getters/setters. I see your point mentioned on a different thread:
I think a get/set(boolean) for the NodeSPI is fine. I'm more concerned about the underlying implementation: It's just likely that the set of properties of a node will expand over time. What will inevitably happen is you'll want to add more methods to NodeSPI. The idea is to add some potential for future expansion.
If you think of the Tree as somewhat modeled off of a file system, the need for meta-data comes up time and time again. Maybe Java annotations can serve this role? But really you need something more dynamic.
Somewhat off-topic, but I think we should think about a similar implementation approach for Option. I think we're going to start replicating those some day, and we're also likely to add new flags over time. If I'm thinking correctly, use of an EnumSet *may* help maintain serialization-compatibility between releases as long as we:
1) Don't remove enum constants from the enum we use for the flags.
2) Only add new enum constants at the end of the list; i.e. don't change order.
3) Don't replicate a new constant if we're interoperating with a previous release that doesn't understand it.
Again, I'd front this with an interface that defines what these options are ... just from a programming standpoint, it is clearer to have a set of methods rather than an enum to refer to, IMO.
But yeah, certainly +1 for following this approach with the Options as well.