We won't give full control over the tree markup (because it is to complex and easy to get wrong, affects style and functionality) but it should be easier to control the tree node label content including markup. Currently if you need markup in the node label you need to use a custom node renderer which requires using JavaScript. 

If we allowed HTML markup for the node label you could put data attributes on the markup but it would not be the best way of working with the tree. It is generally better to get the adapter layer node associated with the view node and operate on that. If you have specific functionality in mind for these data attributes it would be good to know what it is.

I did not understand “capture nodes”.

When the treeView is created from APEX lists as in side nav menu the tree data comes from temporary markup and this is why things like data attributes are not preserved. We could consider moving arbitrary or specific data attributes into adapter node properties. We already support a number of data attributes. The markup rules are here https://docs.oracle.com/en/database/oracle/apex/22.2/aexjs/treeView.html#from-markup-section 

In a Tree region no markup is generated by the server. The data is JSON so there is no way to provide data attributes (except in node label Markup). Again it is best to put arbitrary data for for use by the client in the adapter node. The current tree region doesn't support this. There are hacks for overloading the tooltip property with arbitrary amounts of data but this also requires JavaScript. We should allow arbitrary data in the adapter layer node. 

Summary: 
Agree, make it easy to add HTML to node labels. 
Agree, allow arbitrary adapter node properties (from the region source). 
Not sure if this should be done in the existing Tree region or a new tree region that has more capabilities. 
It is not clear how much if any of this idea applies to trees from lists such as the left nav menu.

Hi John,
I'm a bit late on replying, sorry about that. I hope the explanation below helps clarifying.

By capturing the node, I mean being able to add actions or grabbing specific values from each node that are not it's text content. For example, I have a treeview that is an abstractions of the end users menu and they can right click on node (menu items) to change icons, links, text, etc… Drag and Drop was also requested a few times.

Another nice thing that adding html would do is the capacity for checkboxes, icons/images and inputs for quick editing.

Hi John,

it would be awesome if additional columns from the source of tree region that are not used in tree attributes (labels, tooltips, ids, etc.) were available in tree's node object properties.

For example region query returns column DISABLED and after calling treeView.getNodes returned nodes have not only label, id, icon… properties but also property DISABLED, so i can use it in custom implementation of adapter's function isDisabled.

It would be simple and elegant solution!

Hi Igor, 
I agree that additional columns should be allowed in the node. Similar to what you can do with Interactive Grid with hidden columns. 

For a work around see https://hardlikesoftware.com/weblog/2018/04/24/apex-18-1-new-region-features/ download the app and look at page 5 the tree example on the Explorer tab. It stores extra data in the tooltip node property. If you are customizing the adapter you can separate out the tooltip property into separate node properties in the adapter.