How to read this marble diagram?

I have already gone through https://projectreactor.io/docs/core/release/reference/apdx-howtoReadMarbles.html.

But I cant seem to understand, how this would map to here. Where does subscribe, onSubscribe, request fit in this diagram? Why did the initial green circle transform to a square if there is no subscribe in the initial timeline?

  Flux.just(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
        .flatMap(i -> Mono.just(i + 1).delayElement(Duration.ofMillis(10)))
        .subscribe();

Marble diagrams are used to show what a particular operator does, not to teach you the basics about how publishers and subscribers work. In this case, flatMap doesn't do anything noteworthy with the subscribe and request signals, so they are not shown. The diagram presumes that you know that nothing happens until you subscribe().

To spell it out for you, when you subscribe to the output flux produced by flatMap, the output flux subscribes to the source flux with some internal subscriber that implements the flat map logic. Whatever your subscriber requests, the internal subscriber will also request the same amount.

If you really want to draw this on the diagram, it'd just look like an arrow going from the output flux to the flatMap box, then another arrow going from the flatMap box to the source flux:

(I have run out of space to fit in a "request" signal after the "subscribe()" signal.)

One could argue that showing these signals would be adding noise that distracts the reader from the main point of the diagram.

I don't think I've ever seen onSubscribe being shown as a signal on a marble diagram. When you subscribe to a publisher with some subscriber, the subscriber's onSubscribe gets called with a Subscription provided by the publisher. I don't think there is any operator that changes how this works. If you really want to show this on the diagram, I suppose you could draw it as arrows going the opposite direction, after each "subscribe()" arrow.

Here are some operators where showing subscribe/request signals on the diagram actually helps.

The diagram for the two-parameter flatMap overload shows a "request(2)" signal being sent to the source flux. This is used to show how the concurrency parameter affects the initial demand.

The diagram for delaySubscription(Publisher) shows "subscribe()" signals. After all, how are you going to visualise that the "subscribe()" signal is delayed, without actually drawing the signals?

The diagram for takeLast(int) shows a "request(unbounded)" signal at the beginning, indicating that no matter what the subscriber of the output flux requests, it is always going to request an unbounded number of items from the source flux.

The diagram for timeout(Duration) shows "subscribe()" signals, because without them, it could be unclear when exactly the timer (the green rectangles) starts counting down.