The fluent notation of the streamed pipeline is what's causing this confusion. Think about it this way:

limit(3)

All the pipelined operations are evaluated lazily, except forEach(), which is a terminal operation, which triggers "execution of the pipeline".

When the pipeline is executed, intermediary stream definitions will not make any assumptions about what happens "before" or "after". All they're doing is take an input stream and transform it into an output stream:

Stream<Integer> s1 = Stream.of(1,2,3,4,5,6,7,8,9);
Stream<Integer> s2 = s1.peek(x->System.out.print("\nA"+x));
Stream<Integer> s3 = s2.limit(3);
Stream<Integer> s4 = s3.peek(x->System.out.print("B"+x));

s4.forEach(x->System.out.print("C"+x));

• s1 contains 9 different Integer values.
• s2 peeks at all values that pass it and prints them.
• s3 passes the first 3 values to s4 and aborts the pipeline after the third value. No further values are produced by s3. This doesn't mean that no more values are in the pipeline. s2 would still produce (and print) more values, but no one requests those values and thus execution stops.
• s4 again peeks at all values that pass it and prints them.
• forEach consumes and prints whatever s4 passes to it.

Think about it this way. The whole stream is completely lazy. Only the terminal operation actively pulls new values from the pipeline. After it has pulled 3 values from s4 <- s3 <- s2 <- s1, s3 will no longer produce new values and it will no longer pull any values from s2 <- s1. While s1 -> s2 would still be able to produce 4-9, those values are just never pulled from the pipeline, and thus never printed by s2.

skip(6)

With skip() the same thing happens:

Stream<Integer> s1 = Stream.of(1,2,3,4,5,6,7,8,9);
Stream<Integer> s2 = s1.peek(x->System.out.print("\nA"+x));
Stream<Integer> s3 = s2.skip(6);
Stream<Integer> s4 = s3.peek(x->System.out.print("B"+x));

s4.forEach(x->System.out.print("C"+x));

• s1 contains 9 different Integer values.
• s2 peeks at all values that pass it and prints them.
• s3 consumes the first 6 values, "skipping them", which means the first 6 values aren't passed to s4, only the subsequent values are.
• s4 again peeks at all values that pass it and prints them.
• forEach consumes and prints whatever s4 passes to it.

The important thing here is that s2 is not aware of the remaining pipeline skipping any values. s2 peeks at all values independently of what happens afterwards.

Another example:

Consider this pipeline, which is listed in this blog post

IntStream.iterate(0, i -> ( i + 1 ) % 2)
         .distinct()
         .limit(10)
         .forEach(System.out::println);

When you execute the above, the program will never halt. Why? Because:

IntStream i1 = IntStream.iterate(0, i -> ( i + 1 ) % 2);
IntStream i2 = i1.distinct();
IntStream i3 = i2.limit(10);

i3.forEach(System.out::println);

Which means:

• i1 generates an infinite amount of alternating values: 0, 1, 0, 1, 0, 1, ...
• i2 consumes all values that have been encountered before, passing on only "new" values, i.e. there are a total of 2 values coming out of i2.
• i3 passes on 10 values, then stops.

This algorithm will never stop, because i3 waits for i2 to produce 8 more values after 0 and 1, but those values never appear, while i1 never stops feeding values to i2.

It doesn't matter that at some point in the pipeline, more than 10 values had been produced. All that matters is that i3 has never seen those 10 values.

To answer your question:

Is it just that "every action before skip is executed while not everyone before limit is"?

Nope. All operations before either skip() or limit() are executed. In both of your executions, you get A1 - A3. But limit() may short-circuit the pipeline, aborting value consumption once the event of interest (the limit is reached) has occurred.