Since policy routes are evaluated top-down, you can work around this limit by placing a more specific entry matching traffic from internal subnet A to internal subnet B.
However, this should be less than comfortable if you have many different networks attached to your internal interface.
In this case, I would recommend you a trick I once used:
since Fortigate devices ignore QoS marks, you should sign your "internet" packets on the firewall-facing port of your Cisco switch with a specific TOS and then use that mark in your policy-route.
You're kind of thinking about it the wrong way, but I'll try to explain.
When you purchase bandwidth from an ISP, this is called transit (colloquially in the industry). Assuming you've got yourself some PI space (1.0.0.0/8, for example), you're paying your ISP to get your bits from your network to other networks. So say your AS is 6500, and your ISP is 3356. Bits from any other ASN will also need to transit AS3356 to get to you. Let's say that there's another ASN (6501) that buys transit from a different ASN (7224). AS3356 and AS7224 are peers. Now, in order for bits to get from AS6501 to AS6500, the path goes like this:
AS6501 -> AS7224 -> AS3356 -> AS6500
Now if you set up peering (also a colloquial industry term**) with AS6501, this eliminates the need to get bits from you to AS6501 via transit and vice versa, thus reducing your cost, AS6501's operator's cost, and also usually results in reduced loss/latency between your networks. Everybody wins! Now the path looks like this:
AS6501 -> AS6500
Your original scenario wouldn't work in the real world, because the assumption for AS6501 would be for it to incur a cost to get your bits across it to you from the ISP(s). AS6501 wouldn't be getting benefit by hauling your bits across it to your ISP so you don't have to pay your ISP. What's more likely is AS6501 would charge you to do this, at which point, you might as well just pay your ISP(s) anyway.
** The term peering is overloaded. It can be both used to describe a BGP session (e or i variety), as well as the colloquial/political sense, which means you and another network connect to one another and directly exchange traffic (via BGP) for mutual benefit - think opposite of transit. If you're running BGP with your ISP (transit), you're still technically peering with your ISP, because it's an eBGP peering. To help avoid confusion, it's better to use peering to refer to the act of exchanging traffic with another network at no cost (note that this isn't always the case) and BGP session to refer to the actual technical term for exchanging prefixes via BGP (iBGP or eBGP) with another router, whether a cost is involved or not.
Best Answer
You're right, if you don't take any measures this could happen. It's a violation of the acceptable use policy of most IXP's I know, but still you want to prevent it from happening.
Your first solution is a good thing to do and will solve your problem. Just make sure you don't keep track of session state in iptables, that will probably kill performance or even your router.
You could consider to do outbound filtering as well in a similar way: do not allow packets to leave your network originating from unknown sources. This will prevent prevent hosts in your network from sending spoofed IP packets, which are commonly used in DDoS attacks.
I wouldn't implement the second solution. It's complicated and doesn't scale well if you have multiple routers handling your transits and peerings or if you have a large number of peering sessions (a couple of hunderds on an IXP isn't that uncommon).
On all the hardware router platforms I know this problem is solved in configuration by configuring RPF on the outbound interface and/or by writing filters.