Quite a nice project so far!
Been lately looking at a couple of the tree solutions and even started writing my own for fun to learn about what really matters, since I too haven’t found very good free solutions and on the fence whether to spend those 80$ on the top notch solution out there…
Your implementation is neat and slim! The editor is fine, not sure rewriting to the new Unity api would be worth it, however I’d wish for the possibility to visualize some internal state within the view. At least one or two lines. Of course it might be troublesome when the nodes do not all have the same size anymore unfortunately, but it’d help in many debugging cases where you do not want to click every node separately.
Simple example: Seeing the number of repeats left in a repeater node.
Another suggestion: When clicking in the behavior tree window, it’d be nice if the inspector window would automatically jump to the game object that holds the tree.
Btw. it might be neat to link this thread in your entry on the asset store. People like to have a support thread, even if you won’t answer all that much etc. as it’s a free project.
One thing that makes me wonder, why exactly are the nodes monobehaviors?
When I first read the description of your project, I thought one would need to pull every single node as a script onto an object in the hierarchy (as that’s why you usually use monobehaviors), but that’s not the case from what I see in the examples. The nodes do exist “virtually” without a separate, real game object except for the singular one that contains the main script and blackboard, right?
Is it just so we can use the update and start method somehow if we wanted to? That’s not really typical for BTs after all.
Thing is, monobehaviors have a bit of an overhead (especially regarding code reload time because Unity interprets them in a special way) and sometimes you want to instantiate BTs for many enemy entities for example.
Last but not least, the sub-tree approach is a bit suboptimal unfortunately. Modularity is one of the big strengths of BTs and actual modularity needs the possibility to re-use the same sub-tree independently from its instances. Your tight coupling between parent and child trees unfortunately does not allow for that.
Furthermore what if I want the same tree on 10 enemies that otherwise are very different? Could perhaps work with nested prefabs, but that’s not the smoothest workflow for this.
How about if instead, just like your Monobehavior nodes are virtualized, you make the whole tree virtual?
Instead of tying the actual tree instance to an object, let that work as if the game objects with a tree were like files: Game objects that can be anywhere in the hierarchy each have a tree.
Or even better: Make them scriptable objects!
Then your MBT executor script takes a reference to that MBT instance (or just the scriptable object) like before, however instead of actually using that linked instance, a new, copied instance of the tree shall be generated upon start (ideally from a pool or buffered).
Finally the MBT Executor would get a button like “view tree” that tells the Behavior Tree window which virtual instance to show. Or you can give the window a dropdown menu with all executing instances.
This would allow to reference the same sub-tree in multiple main trees seamlessly too.
The result of this would be that the game objects with the actual tree are only there for designing and debugging. With that you could even offer a “build mode” where the file-like game objects are just destroyed upon launch for maximum performance.
If you use scriptable objects, that can even be omitted as a whole of course.
EDIT: The more I think about it the more I find “ScriptableObjectTree” would be an ideal way (if you don’t wanna introduce your own file format etc. like the commercial big players), even if it does not have the same ring to it 
Now I wrote way more than intended, haha.
Am looking forward to what you do with this project in every case 
