JSTL/JSF problems have nothing to do with the XML (namespaces). They have to do with the fact that JSF and JSTL are 2 different technologies.
JSTL is designed to add functionality to JSPs, although there's a whole 'nother argument about coding logic on JSPs.
JSF started out as JSPs, but it evolved into something much different. The actual JSF component object model is a 2-dimensional graph (tree structure) which is fed incoming (validated) data, then eventually to a rendering engine (usually, but not always HTML). The linear approach of JSTL and even raw HTML doesn't fit in well with that. In JSF 1.0, you had to kludge your way around it using "verbatim" tags or all the non-JSF content tended to pile up in an unwanted corner.
Later versions of JSF handle that kind of stuff better, but there are still limits, so it's better to avoid JSTL. As I've said before, JSF has its own ways of handling stuff like that and doesn't need JSTL, especially since the JSF equivalents are - naturally

- aware of how JSF works.
RichFaces is an extension to core JSF, so if a RichFaces custom component can offer something that core JSF can't use it, but often the core JSF tags are sufficient.
You really do need to lose the idea of "iterating" on a View. A rendered View is a static 2-dimensional object. If it contains a table, the table is likewise a static 2-dimensional object. If I printed it out and handed it to you, you would have absolutely no way of determining whether that table had been produced by iterating top-to bottom, bottom-to-top, middle-to-outside or even in a single parallel operation that generated all the rows at once. MVC is all about separating the logic from the display. You can see this in JSF, in that the model object for a dataTable can be (among other things) a Collection, but the actual enumeration of the items in the collection is not done in user code - the JSF Controller handles that. Typically, it uses an Iterator internally, but other mechanisms are possible.
The one thing that is peculiar to JSF is that complex data cannot generally be directly used as a Model. In particular, the dataTable needs a dataModel, since that construct not only manages the data being presented, it also maintains the cursor that allows such things as telling which row you selected when you click on a commandButton/commandLink within a table. You can front a HashMap with a datamodel like so:
I typed this in from scratch/memory, so expect some defects. In the case of 3 different hashmaps, I'd probably subclass ListDataModel to create my own HashDataModel class to minimize redundant work.