That's called recursive next-hop lookup (or something along those lines) by most vendors. Most equipment will handle that just fine, but its not a particularly good practice to get into for static routing.
FWIW, iBGP typically works this way. The "next-hop" carried in an iBGP session is the next-hop on the far side of the autonomous system and some sort of IGP (typically OSPF, less commonly, IS-IS, RIP, or even static routing) is used to recursively resolve that iBGP next-hop to an immediate next-hop.
If you do too much of this, the gear is having to do more and more layers of recursion to find the real next-hop. I've never really tested any gear to see how many times it would recurse to find a real next-hop, but I wouldn't be surprised if the limit were 3 or 4.
You are almost correct.
1) I have static routing like this : Router3 - > Router2 -> Router1 -> Router0
ad 1 : there won't be ICMP redirect, because next hop of Router 3 , which is Router 2 isn't on the same subnet as PC0 is. Every time PC0 will communicate with PC1 the path will be PC0 -> Router3 -> Router2 -> Router1 -> Router0 -> PC1
Absolutely correct. Since Router3 doesn't know the full path, only the next hop, it would just forward the packet to Router2
2) I have static routing like this : Router3 -> Router1 -> Router0
ad 2: At the begining communication will be PC0 -> Router3 -> Router1 -> Router0 -> PC1 Then ICMP redirect will send and next communication will be PC0 -> Router1 -> Router0 -> PC1 and ICMP redirect will send again and next communication will be PC0 -> Router0 -> PC1
Almost. You are correct in saying that Router 3 will send an ICMP Redirect to PC0, informing PC0 that the proper 'next-hop' to get to PC1 is to use Router1. However, when the ICMP Redirect is sent to the original sender, the original packet is still forwarded. Which means when Router1 receives the original packet, it will be receiving a packet from a host in its own network, for which a better next-hop exists, also in the same network (Router0). So Router1 will also send an ICMP redirect from the first packet.
So the path of the first packet will actually go Router3 -> Router1 -> Router0 -> PC1. But both Router3 and Router1 will send PC0 an ICMP Redirect informing PC0 of the better next hop. Since Router1's ICMP redirect will come after Router3's, then Router1's ICMP redirect will overwrite Router3's. So the second packet will go PC0 -> Router0 -> PC1.
3) I have static routing like this : Router3 -> Router0
ad 3: At the begining PC0 -> Router3 -> Router0 -> PC1. Then, ICMP redirect and the path will be PC0 -> Router0 -> PC1
Absolutely Correct.
Two final points to keep in mind:
First, in all cases, the ICMP Redirect is temporary. I believe that PC0 will use the information in the ICMP redirect for 10 minutes, before 'going back to' what it knew before... which would prompt additional ICMP redirects, and an additional 10 minutes of more efficient routing.
Second, ICMP Redirect was created when the Internet was a nice place, with trust worthy people. Now a days, the Internet is a dark and scary place, for which you should have very little trust. As a security best practice, most Network Admins prevent their Routers from sending ICMP Redirects and prevent their Routers from 'obeying' ICMP redirects. Similarly, a lot of client OS's also flat out ignore ICMP redirects.
The reason for this is it would be very easy to abuse the ICMP redirect to become a Man in the Middle. If you and I happen to be on the same network, I could easily send you an ICMP Redirect message that tells you the "better next hop" to reach your [Facebook, Banking, e-Commerce, Intra-net Portal, anything] network is through my own IP. Voila, instant Man in the Middle.
As such, I think its good to know the basics of ICMP Redirect, but I think it isn't very functional to spend much time mastering how they work. Its nearly across the board disabled and/or disallowed -- for good reason.
Best Answer
The routes you proposed are incorrect according to the diagram you provided, the routes you need to configure on R2 and R3 are
The reason for this is that R2 and R3 do not have an interface connected to the 172.16.128.1/19 network, only R1 does. Since that network is not directly connected to R2 or R3, you cannot use it as a "next hop" for your static routes - it is not the next hop. R2 and R3 would have to forward traffic to R1 to reach the internet first, so it must be configured as the gateway for the default routes on R2 and R3.