Lack of INTRODUCE2_ACK
Seen from the POV of an HS client trying to connect to a service:
When you send INTRODUCE1 the IP sends you INTRODUCE_ACK. It sends INTRODUCE2 on to the service. The service responds by connecting to your RP. But there is no INTRODUC2_ACK that goes via the IP. So if you get INTRODUCE_ACK but nothing tickles the RP you don't know if it was the (paths to the) IP, or the (paths to the) RP, or the service, that's faulty.
This doesn't seem desirable. In particular, the client would like to know whether trying a different IP is likely to help.
Perhaps if the protocol had an INTRODUCE2_ACK that would enable some kind of attack? That would be a good reason for this omission. It ought to be written down somewhere, then.
(Such a message could be sent by the HS after receiving the INTRODUCE2, or after reaching or failing to reach the RP. These would have different implications for who would learn what.)
CC @dgoulet