Not an issue I've ever had?
As far as I'm aware, it was simply to move the BPL library files into the individual executables. Normally, we have multiple Delphi EXE's within our application. The BPL files (kind of the Delphi equivalent of a DLL as I understand it) are normally stored externally to the EXE's and shared between them. In order for TC to pick up the native methods and properties, the BPL libraries need to be embedded in the compiled EXE.
For me, this results in a slightly bigger EXE. But functionally, it behaves exactly the same. All my grids, trees, tables etc all behave the same. Included ones running off underlying datasets (fiddly!) and ones we have customised slightly, added extra event handlers to, etc etc. It's all the same.
Can I check, when you say behaves differently, do you mean when you use it manually, or when you drive it through scripts?
Manually, I would expect identical behaviour. But with scripts, if you invoke methods the user would not normally trigger (quite possible once you have access to all the native stuff), I could see that having the potential to cause some strange behaviour. And with some of the custom controls, I had to mimic user behaviour in very specific ways for them to behave correctly.
For example: A custom treeview. We added event triggers that are activated by a click on the Tree object. Clicking the checkbox attached to a node via the usual Click/Check/Whatever method did not tigger the event. I had to find the node. Then use it's properties to get it's co-ordinates relative to the grid it lived in. Then apply the click to the grid object at the calculated co-ordinates. Otherwise the event did not trigger. Without some help from the dev team, working things like this out can be nigh on impossible!