This looks like a weird wrinkle in overload resolution. FWIW, adding this explicit overload to the stdlib makes the second snippet work as expected:

extension LazyMapSequence {
  public var lazy: LazyMapSequence { return self }
}

(We have the same definition in a conditional extension on LazySequenceProtocol, but sadly that doesn't seem strong enough.)

/cc @xedin

FWIW: on current master the double-lazy expression is ambiguous, so the only option is to use the single .lazy, which is an intended use anyway.

@moiseev Interestingly enough version with two "lazy" doesn't type-check on master because it's ambiguous in both 3 and 4 mode:

(0...).lazy.map { $0 * 17 }.lazy.prefix(while: { $0 <= 123})
error: ambiguous use of 'map'
(0...).lazy.map { $0 * 17 }.lazy.prefix(while: { $0 <= 123})
       ^
Swift.LazySequenceProtocol:5:17: note: found this candidate
    public func map<U>(_ transform: @escaping (Self.Elements.Element) -> U) -> LazyMapSequence<Self.Elements, U>
                ^
Swift._SequenceWrapper:2:17: note: found this candidate
    public func map<T>(_ transform: (Self.Element) throws -> T) rethrows -> [T]
                ^

@xedin yeah I noticed. And it's great. I nudges the user toward the right solution, i.e. using a single .lazy.

Oh right, I tried my stdlib workaround on a swift-4.1 build.

A direct definition of `LazyMapSequence.lazy` makes the expression compile on master, too. (I don't think we need to add it, though.)

@moiseev filed SR-6991 where the opposite is true (extra .lazy keeps it lazy).