I'd probably split this into two loops, instead of branching in the main loop on something which is going to always be false up to some point, then always true after. It really is two loops.
Maybe:

var buffer = ListQueue<T>(length + 1);
while (buffer.length < length) {
  if (iterator.moveNext()) {
    buffer.add(iterator.current);
  } else {
    return;
  }
}
while (true) {
  yield List<T>.unmodifiable(buffer);
  if (!iterator.moveNext()) return;
  buffer..removeFirst()..add(iterator.current);
}

(Why don't we have a do { beforeTest } while ( test ) { afterTest } construct?)

I'd probably split this into two loops, instead of branching in the main loop on something which is going to always be false up to some point, then always true after. It really is two loops.

Done.

Maybe:

var buffer = ListQueue<T>(length + 1);
while (buffer.length < length) {
  if (iterator.moveNext()) {
    buffer.add(iterator.current);
  } else {
    return;
  }
}
while (true) {
  yield List<T>.unmodifiable(buffer);
  if (!iterator.moveNext()) return;
  buffer..removeFirst()..add(iterator.current);
}

I don't think the ListQueue actually makes this more efficient. You're still copying length elements on every iteration in the List.unmodifiable() call.

The "slices" name is not particularly telling.
Not sure which short-ish verb would better describe "chop list into equal sized chunks" through.
Ideas welcome.

Ruby calls it each_slice, from which I got this name. RxJS calls it bufferWithCount, but that seems too strongly tied to its streaming API to use here. A Haskell package I found calls it chunksOf.

I suppose we could call this chunks, but I'm not sure that's much clearer.

Returns -> Creates

Ditto below (I still don't think "Returns" is ever the best word to start a DartDoc with).

Returns -> Creates

Also Returns->Creates in this file.

"Returns" is very common.

cc @munificent for opinions on this.

I would do "Returns" if it were my code.

Well, I'll agree to disagree then.
To summarize my reasoning: "Returns" is never the best word to start a DartDoc with.
It's redundant. (All non-void methods return something, so it's like adding "when called" to the method. It's a given).
If it's the most important thing to say about the method, then either the method should be a getter, or it's a parameterized-getter-like method, and I'd document it with a noun phrase too (so remove the "Returns"). Own up to the fact that the method is described by a noun phrase, don't try to hide it by adding "Returns" in front!
If not, then it shouldn't be the first word of the DartDoc. Say something about what the method actually does, not just what it returns.
Finally, we recommend having a paragraph of the DartDoc starting with "Returns" to document the return value. Having the first (short, one-line) paragraph take over that makes it harder to do a satisfactory description of the returned value, and having two sections starting with "Returns" looks odd and can be confusion.

Tl;dr: Using "Returns noun-phrase" as the primary DartDoc of a method is technically following the style guide, but missing the point. It's always better to use something else.

But if people want it, they can have it. I'll just keep suggesting improvements!

Yeah, this is a tricky one. In cases like this, I don't think a noun phrase reads right. Those work best when the member sounds like it describes a property or facet of the underlying object. But I don't think most readers would think the list has these subsequences as a fundamental property.

I believe they will think of it more like a calculation that is producing the result. That means a verb sounds better to me, but I wouldn't want a verb that stressed how the result is calculated since that's an implementation to detail. To me, "Returns" works well then. It stresses that the function is producing the value, but abstracts over how.

carve? (Found by browsing Webster Dictionary)

batched or batches, perhaps with something to indicate the argument is the size of the batch, not the number of batches.
batchedByLength(3)

I think referring to "slices" makes the most sense, since (at least for lists) this is returning views of the sort provided by slice().

I agree that slices is a an appropriate name. It's a noun phrase, which does mean that it's defined in terms of the values it provides. And that's fair, but the returned value is an iterable, and I'd document that in terms of its elements (with a plural). So:

/// Contiguous [slice]s of [this] with the given [length].

Don't say "Returns", that's a given. Don't say "Iterable of", that's obvious from the return type too. Just describe the elements of that iterable.

I'll still maintain that the documentation should use a noun phrase when the function is named with a noun phrase. Those two should match.

Consider:

subsequence = [for (var i = 1; i < length; i++) subsequence[i], iterator.current];

Avoids allocating an extra Iterable+Iterator wrapper and might allow a smart compiler to predict and preallocate the length.

(A very good compiler could recognize "for ... in built-in-list.take(n) ..." and convert it to the above, but I don't think our compilers are very good.)

On the other hand, you could imagine ...value inserting a runtime check for EfficientLengthIterable! I think the internals of the compiler are enough of a black box that it mostly makes sense to make the code as readable and semantic as possible.

On the other hand, you could imagine ...value inserting a runtime check for EfficientLengthIterable! I think the internals of the compiler are enough of a black box that it mostly makes sense to make the code as readable and semantic as possible.

I'll still maintain that the documentation should use a noun phrase when the function is named with a noun phrase. Those two should match.