1.
When you call a function (or Blueprint event) that’s replicated, your machine serializes the function parameters you passed in and sends a network message to the other machine telling it to call that function with those parameters.
At some future point (it’s not instantaneous, due to network latency, and possibly due to the RPC call having to be resent if it’s reliable and the packet containing the network message got lost), the server instance of the game will receive that network message, and the networking code on the server will call that function for you. But basically once that function gets called, it’s pretty much just a normal C++ or Blueprint function at that point, and can do anything it wants.
There’s nothing special about it, and you can call absolutely whatever you want on the server from there. You can call any function, whether it’s replicated or not. You can also call client/multicast RPCs to let everyone (or just the requesting client) know about what just happened, that’s a pretty common pattern in multiplayer games where the server/host has authority, clients will ask the server to do something, and the server will respond with another RPC that’s either sent to the person who asked, or sent to everyone with the result. (For example, the client asks to open a door by sending an RPC to the server, the server replies with another RPC back to that client telling them that they can’t because on the server, another player just kicked that door down and it doesn’t exist any more)
On the sending client, you can absolutely call multiple server (or other) RPCs in a row, and they’ll all get replicated.
Ultimately though, to save on network bandwidth you’re ideally going to want to send the smallest number of messages possible that will achieve the result you want.
If you have a server RPC “ServerFunction1” that then calls “ServerFunction2”, the client doesn’t need to call “ServerFunction1” and then ServerFunction2", it can just call “ServerFunction1” and let the server take care of calling the other function.
2.
When you call an RPC, all you’re saying is “call this function on the server”. Only code/blueprint that gets called from that server function will get called on the server. If you call a server RPC, and then do a bunch of other stuff that’s not replicated, none of that will reach the server unless those functions also happen to be replicated.
3.
Switch Has Authority is most useful when you have cases where the code is run both on the client and on the server, and you want to do different things based on whether it’s a client or the server. For example, your BeginPlay/Tick events can be called on both.
For example, you’ll want to check for authority if you’re going to call a multicast RPC, because if you’re not the host/server, then you’ll just call that function locally and not replicate it to anyone.
See the table in this documentation page: