I just want to try to explain why this is not convenient but I'm not sure it will be clear.
In our game, we need to create a prefab at every instance of these tiles, for example, we have a tile where the player starts and a tile where an enemy is. We need to create the player prefab or the enemy prefab, but, we are also using StrangeIoC and we need to perform an AddComponent on these objects, to add a specific script to the prefab dynamically, and it needs to be performed in the context of strangeioc otherwise the mediator does not get created.
So, my idea to solve this was to create a single "fake" prefab with a common script on it which contains some info about what the real prefab should be. Then, on startup after tk2d is ready, a script inside strangeioc can locate all of these "fake" prefabs, and read the data from them , match it to a config value, and then create all the "real" prefabs and destroy the "fake" prefabs.
It can't be solved with a tag because you would then need a different fake prefab for every type.
The solution we have created now, is to remove the prefab from the tile in tk2d, put the special tiles on a layer behind so its not visible, store the data in the fields which I mentioned, but when the scene is loaded, a nested loop through every single tile on the tilemap and check each tile if it contains some interesting data, and then create the prefabs inside our script under the strangeioc context where the mediator will be properly bound to the prefab/view. Actually to me this isn't a totally terrible solution since the scan happens just once at scene load and it's relatively fast, but it is less than ideal. (Perhaps another solution is create the "fake" prefabs with a script that lookup the tk2d tile based on transform position, in theory this could be faster than the nested loop?)
If instead the prefabs had that data already in it, things would be faster. But since we want external designers to be able to create levels and export them in .TMX , they need to be able to create these things once - we can't click on every prefab in the render data and set these values, which is why the tilemap data seems to be an ideal place, since that data is set once for every tile of that type.