There are indeed mulitple issues that led me to use a map of map : 

* a proper custom data structure would be the best here, something that gives the operations needed in fastest time. But to do this, as we need both the data structure in the RoboGuice runtime and RoboBlender (the annotation processor), this means that, to avoid a cycle in maven modules, we would need to introduce a new module (like Blender-lib) to the RoboGuice o Guice project, and I didn't dare doing it.
* so I fell back on using language-provided data structures, hence this map of maps
* hashmaps are supposed to provide lookup in 0(1) average, O(n) worst case with pathological data (that we don't have). A map of map is thus in O(1) average too.
* to circumvent the low meaning-ness of a map of map, compared to having proper structure carrying it, I used quite verbose variable names for those maps. That's the best I could find.

I tried to save on every possible CPU cycle, if a data structure was not needed, I didn't create it to help the garbage collector running less frequently and consuming less user sensitive time. A map of map seemed like a "raw/low-level/fast" data structure that could be justified in that specific case.