What about having randomness? or the option to use a mesh surface among the standard offset?
For this Id prefer to have python dupli support so you could register a duplicator that could dynamically create objects with far more variations without having to make the real objects. and also avoid over-complicating the modifier.
The nice thing about duplis too is you can do render instancing where the modifier outputs a big mesh.
Nice hint ideasman42
One improvement I would like to see is for the array modifier to render correctly. When objects are close together, you get the ugly black overlap problem.
Atom, would need to see a blend file example.
Id like it to, upon applying, the join the polys from either face. to merge edges i guess would be the correct saying.
@ideasman42: You know the bug, when two faces are on top of each other Blender renders a flickering black. It is easy to end up in this state if you start with a single cube and all the array duplicates are inside the initial cube. But it is impressive, graphically speaking, to start from a single object and then expand outward into many. Layer swapping techniques can be employed, but I noticed that the Lux renderer does not have this multiple faces on top of each other problem, like the Blender internal does.
I’m pretty sure that BMesh would ‘fix’ that as it actually supports ‘double-sided face normals’ so to speak(unless I’ve misunderstood),
but I really like the idea put forth by mrjynx, though I would like that option to be available as a separate option from applying
as I might like to apply the modifier either with or without the option depending on the situation. 
@Atom & Felix_Kütt,
this is really nothing todo with the array modifier, rather how the internal rendering engine handles z-fighting, Im not expert in this area however Id guess this is todo with scanline rendering since OpenGL also has flickering artifacts with this. Probably pure raytracing doesn’t suffer the same issue for some reason.
BMesh wont fix this since BMesh will be tessellated before rendering.
Right I was only thinking about viewport for some reason when I said that. :o
still, the feature/option mentioned by mrjynx would be awesome(ly usefull). 
Yea I took the on/off as a given.
One more idea, which was the option to add a face, rather than just merge, as both sides may not meet. bottom view is a side view of add.
Why not just have an option when you use the array modifier on say, a cube mesh with the front and back face missing, drawing it out on a curve, you just merge all the edge verticies together in the average direction of the curve between each piece regardless of distance and any closer try to keep the merges intact, like an auto-bridge and this would only work on holes in the mesh pointing towards each other (not perpendicular to the curve direction).
One could also have an auto hole fill on the end pieces or you can manually fill it and it automatically avoids doing that for all middle sections?
The add faces suggestion suggested in the post above could also be worked into this using the same basic idea.
Nope, sorry
As ideasman said, this sounds like a z-fighting issue. If you want to stop this sort of thing from happening you either delete that face and use the ‘cap’ functions of the array modifier or wait until a remove doubles modifier is possibly added to Blender (shouldn’t be too hard with Bmesh…)
Backface culling in the renderer might also help this, but I dont think that would really be such a good idea…
<EDIT>
As for loading individual modifiers down with tons of options, thats probably a bad idea compared to just adding more modifiers that can… well modify the output of current ones.
</EDIT>
Cheers,
Briggs