This module sounds useful but I'm not sure I'm clear on what it does

Thanks for asking - I know it's a bit confusing, and really only useful for a specific scenario. In my case, that scenario was very important and I found myself needing this in about 3-4 places on my site.

Normal views cache plugins generate a cache key like this:
view_name:display_id:type:md5_of_build_data

With a key like that, there's no way to differentiate between caches for a given argument, so usually, the entire cache is cleared for a given view and display id.

My example of that was for Views content cache. That's a cache plugin that will keep the view cached until a given node type has an add/edit/delete operation -- then the entire cache for that view is cleared.

With this module, you can target only the cache for a given view, display, and arguments.

I'll give you a working example.. Check out the calendar on this page - http://workoutspots.com/nimblefitness. That's a view that shows class nodes. The view takes an NID argument (for the location node that you're viewing) and only shows classes that are referenced to that location.

I used to use Views content cache, and whenever someone added/edited/deleted a class, I would have it flush out all of the caches for that view. But why empty the cache for all 200 locations when I know that the given class will only affect one of them. That's how this module was born...

Remember, as the project page depicts, the only way to clear caches is with custom code.

When a class is about to be saved, I called views_arg_cache_flush(), passing in the node ID of the location. So, only the cached view for that given location node is flushed -- and the rest remain intact. So you have to be careful with this module. You have to know exactly what actions will affect which views, and you have to clear them with custom code.

Now, the views cache keys look like:
view_name:display_id:md5_of_args:type:md5_of_build_data

In the beta3 release, you can pick how many arguments to generate cache keys for. This is useful because those calendars take a second argument of month/year, but I want to ignore that, so I can only pass in an NID and clear for that.

I hope that makes sense. Please ask more questions if needed.

Here's an example of the cache keys in the database for that view:

location_fullcalendar:block:36ba51ad84bf8a85cd2434cb7e0e7d8b:output:55b07f9af2f2e940d94cdebc2cc8c4e6
location_fullcalendar:block:36ba51ad84bf8a85cd2434cb7e0e7d8b:results:19f5eceec689c0d2d1bc9f3471a9837b
location_fullcalendar:block:36ba51ad84bf8a85cd2434cb7e0e7d8b:results:237c7ba575724967e11aa71b89bb8d51
location_fullcalendar:block:36ba51ad84bf8a85cd2434cb7e0e7d8b:results:4f6a5c427aa23bed95009fecc83383e8
location_fullcalendar:block:a66a5369f4c6c99b1aa6d0aa291581ad:output:a8ba8a12bc165c7f76f814992b304dc2
location_fullcalendar:block:a66a5369f4c6c99b1aa6d0aa291581ad:results:0d6046cdaa7cfd8b4bf6ac60b2224cc2
location_fullcalendar:block:e5e77167cc108716fccaec1f05914b1b:output:55b07f9af2f2e940d94cdebc2cc8c4e6
location_fullcalendar:block:e5e77167cc108716fccaec1f05914b1b:results:926555d77af4444f05e6bf11d9c9269c

The first hash is basically just the location's node id. So when a class is added for that location, calling views_arg_cache_flush() then calls cache_clear_all() using "location_fullcalendar:block:36ba51ad84bf8a85cd2434cb7e0e7d8b" as a wild-card. So only caches pertaining to that get removed, and the rest remain.

views_arg_cache_flush('location_fullcalendar', 'block', $node->nid);

Or, for multiple arguments

views_arg_cache_flush('location_fullcalendar', 'block', array($node->nid, $something->else));

Sounds about right to me. Why don't you try it out, then if you have problems, come back, show me your view and your code, and we'll make it work. You can select cid from the cache_views_data table to see the entries, and check if they cleared.