I have been playing a lot with control authoring in .NET and also in PB. I also tried the external vuo route and although it is a little more difficult, it was very doable. But it wasn't unitl PBNI that things started to get easier. The biggest hurdle for me before was translating all the GDI+ code in .NET to equivalent GDI in PB. So I came out with a port of System.Drawing in .NET to PB in order to make it easier to port drawing code. And as long as I have a subclassing and hooking class, it should be all possible.
So for the new Kodigo, it will have all the basic controls found in other control suites but not found in native PB. I will carry over existing controls in Kodigo, and some of the controls from Brad's AdvancedGUI. But it will all be based on a core control/drawing framework. It will be roughly based on how .NET 2.0 System.Windows.Forms does drawing. It's amazing what you can learn with Reflector and hours of reading decompiled code and trying to decipher the architectural decisions behind them.
On peeve I have with powerbuilder is the menu. I am not really satisfied with the implementation of contemporary menus in PB 10.5 above. So one of the controls will be inline with Aart's popular CoolMenu. But it will not be implemented as a DLL but will be written in PB through application hooking. I ahve already tried it and it works. I learned a lot from VBAccelerator. Don't let the sitename fool you, there are a lot cutting edge stuff in that site and VB classic is close to PB in terms of capabilities.
But in order to start, I would have to get the architecture right because I learned from the Kodigo BETA that you have to consider everything before starting on even one control. Things like theme managers, control part renderers, transparency through parent painting, serialization, etc. should all be considered and supported through generic control helper classes befoer writing a simple buton control. At least I am done with the GDI+ port, it is now design time.