Attempts to be clever with destination on 'Add member' links don't play nicely with block caching

Problem/Motivation

I'm noticing UX badness on a site I've been building regarding the "Add member" local action at /group/N/members. There's a lot of effort to try to set a meaningful destination query param. However, in my testing, it appears that the caching of the local actions block is thwarting those efforts, and depending on the first path you use to visit this page (either from /admin/group or from /group/N), the local action link is getting cached into the block. So if you try to access the page from the other path, the cached block is still forcing you back to the first destination after a cache rebuild.

This is extremely annoying for admins trying to add a bunch of members to a specific group, since if they happened to get there from /admin/group first, even if I instruct them to click over to the group member page directly, it still sends them back to /admin/group after every new member.

Steps to reproduce

1. Install group (this site is still on 3.2.2, but I imagine the same would be true with any version)
2. Create some groups
3. Clear all caches
4. Visit one /group/N/members page directly
5. Go back to /admin/group
6. Click the "Members" operation link for that group
7. Inspect the URL for the 'Add member' link and notice a destination that sends you back to /group/N/members, not /admin/group
8. Re-visit /admin/group
9. Click the "Members" operation link for a new group.
10. Add a member, get sent back to /admin/group
11. Click on that group's name (not the operation link), and end up at /group/N+1
12. Click on the "Members tab" and end up at /group/N+1/members
13. Inspect the URL for the 'Add member' link and be sad to discover it's still got the /admin/group in the destination cached from the previous visit.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes