Cool! Glad that scaling worked well. I only know that some of the debug info doesn't consider scaling and thus will be off.
But this reminds me: right now the anchorpoint of tilemaps is at the lower left corner, and TKTilemapNode doesn't support changing the anchorPoint, so scaling always centers on the lower left corner of the map. However you can add the map node to a parent SK/CCNode, offset the tilemap node from the parent node, then scale the parent node to achieve the effect of centering the scale operation on the parent node's position rather than the tilemap node's origin. I thought it's better that way than to further complicate the grid conversion & rendering algorithms.
As for performance, it's generally unoptimized at the moment. I know there's a number of inefficiencies in the rendering because my approach is to make it work correctly first, then optimize it. For instance right now I update (assign) each node's texture regardless of whether it remained the same compared to the previous frame. It's also a debug build.
In this particular instance, Iso6 has 29 layers while Iso8 has 11 according to my counts. Could be that each layer adds a layer of inefficiency so to speak. In SK it probably means 29 vs 11 draw calls at a minimum. The size of the sprites also makes a difference, but here it's not significant (64x32 vs 56x28). This needs further analysis.
The TKNodes are super-helpful. I can bend the Cocos2D API to be exactly like Sprite Kit's and not having to worry about the differences. Plus, in the future it will be possible to compare SK vs CC head to head with the same code. Will be interesting to see the performance results when I pit them against one another. Such engine comparisons are popular so I'm hopeful that this could give the site some link juice and extra traffic.