def ichain(seq):
  for s in seq:
     for t in s: yield t

This is like itertools.chain except seq is lazy-evaluated element-by-element.  Obvious use cases:

# equivalent of perl's "while (<>) { ... } "
for line in ichain(all_lines_of(f) for f in list_of_filenames):
   do_something_with(line)

# generate infinite sequence 1,1,1,2,2,2...
seq = ichain(repeat(i,3) for i in count(1))

Also requested: it would be nice to be able to get the current counter value from a count() instance without incrementing it, e.g.
   c = count()
   ...
   i = c.getvalue()

This is clearly useful since repr(c) does something like that internally.

Am rejecting ichain() because it adds too little in the way of functionality to be worth the confusion associated with having two like named functions and two ways to handle most problems.

Also, I think that some the use cases for lazy-evaluated inputs are better served by using explicit for-loops and not itertools (too much magic underneath the hood).  I do see some value in having lazy-evaluated inputs but do not think it is worth complexifying the module any further.

FWIW, the first example has no need for lazy evaluation.  I would write it as:

   for line in chain(*map(open, list_of_filenames)):
        do_something_with(line)

Or, just use plain vanilla Python:

   for filename in list_of_filenames:
       for line in open(filename):
            do_something_with(line)

Please submit a separate feature request for count.getvalue().  I'm thinking it should be a read-only attribute instead of a method.  The only downside is that it complicates the explanation of an otherwise trivially simple tool.  

Well, I use ichain all the time in my own code, and the difference doesn't seem hard to explain.  The chain(*map(open, list_of_filenames)) substitute is no good because it opens all the files simultaneously, and there might be millions of them, so you run out of file descriptors.  Not having ichain in the module leads to users writing such inferior substitutes, which can work for small examples and end up breaking or performing poorly with large examples.  Also, using nested for-loops isn't so nice if you want to pass the resulting generator to some other function (maybe islice or groupby or something).  It means you've got to wrap the statements in a named function, which I suppose is doable, but ends up with unnecessary Java-like code bloat.

A read-only attribute is fine for count.getvalue.  I guess it could be count.value instead of getvalue.  I'll submit a separate RFE as suggested.

Note, nowadays this is implement as itertools.chain.from_iterable .