Yeah, I do like the look of Retire_Pct, but it has a hardcoded limit imposed where it won't take effect if there are enemy units nearby, so it won't have predictable results.
Though, if you want my two cents – I don't think some random chance to lose an entire boat and everything on board is a good idea. I recall that being incredibly frustrating, way back in the day. It's just too big of a random effect IMO.
That's fair. I was thinking more a case of "you probably don't want to hang out in the sea for long" so I wouldn't want that to be there until a boat has been in the deep ocean for a while, which is also not currently possible. Eh, a fuel like system would probably be better.
If it's "possible but difficult invasions" you're after, have you considered giving those terrain types a negative defense bonus? Would make it easier for defenders to fend off the invading force, assuming they get a hit in.
I did briefly consider it, but I never tried it out. The problem I have with that is it makes the danger entirely dependent on other civilizations. I also do want these natural barriers to limit exploration, and it wouldn't do that unless you could guarantee barbarian presence at all times. :/
There is a way actually – it's a bit hacky though. You can't turn specific terrain into refuel points, but you can make an (invisible, unbuildable, unpillageable) extra native to your land units that serves as a refuel point, with requirements that mean it can only exist on non-difficult land.
Now, the difficult part is getting that extra everywhere. From 3.0 on you could just give it the "Appear" cause and an appear chance of 100%, but in 2.6 you'll have to use Lua script (here's where it gets hacky): Since there isn't a terrain change signal, you'll have to run a routine every turn (turn_started signal in 2.6, turn_begin from 3.0 onward) to iterate over the entire map (whole_map_iterate()) and place the extra (edit.create_extra(tile, name)) on every tile. The following code in script.lua might work for 2.6 (haven't tested it in the slightest):
Huh, that's real interesting! I'll have to look into that. Thanks! (Probably will be a no-go in 2.6 since as you said that method is bound to be massively inefficient, but this just might solve the problem for v3.0.)