Processing logic for return traffic in stateful inspection

Yes,  routing table is check at the first packet starting the session and the first reply packet. 

If there's a routing change during the session ttl, the routing table is checked again to confirm if the change affects the session.

You need to drop/forget your obsession "need to use policy routes". Unless you're using like a 25+ year old device or from the last century. Most of modern NGFWs handle all traffic as "sessions" or "flows", which includes initiation, returning, termination/time out. 

Unless you want/need to "initiate" a session toward a specific outgoing interface while multiple outgoing interfaces/routes for the traffic are available, you never need policy routes.
I feel like you're trying to do what those NGFWs are already taking care of at least for last 25 years or so.

Toshi

Thank you all for the kind advice.
You have greatly accelerated my understanding.

I have one last request. Could you please let me know if you know of any packet flow documents for return traffic?

I'm looking for a return traffic version of the packet flow explained in the following URL:

https://docs.fortinet.com/document/fortigate/6.0.0/parallel-path-processing-life-of-a-packet/478386/packet-flow-ingress-and-egress-fortigates-without-network-processor-offloading]

Thank you
Kenji

Would the constant ping still be the same session? Maybe that isn't the best example. The main thing I am trying to figure out is how firewall changes are applied to existing sessions. Or in other words how existing sessions are blocked when the policy that allowed them to exist in the first place is removed.