Over the past few weeks I've started working on a 2.x branch for the Purge module. It will be a major upgrade from the 1.x series and will make giant leaps in human and technical usability. These new functionality will not be backported to 1.x by me but I welcome patches to improve it. A bugfix release of the 1.x branch will follow at some point but scarse development time will be put into the new branch first.

Configuration storage in database table. (95% done)
The individual proxy configurations are stored in a database table. This allows for a great many extra options without the hackish proxy url scheme. Individual proxy configuration allow for adding custom domains and headers and settings advanced options like parallel execution and nonblocking requests. You can easily combine multiple proxy configurations. Also removes the configuration size limits imposed by the 1.x scheme improving scalability.
Todo: upgrade from 1.x, system and template configurations.

Admin Gui. (75% done)
The partian configuration by the non intuitive proxy URL scheme wil be replaced by a spiffy gui that allows to edit proxy configurations through detailed forms.
Todo: Optional integration with Ctools import/export, domains and headers debugging, machine name validation, ajax forms.

Dependencies and integration (0% done)
Purge 2.x will have no dependencies. The Expire module integration is now optional. The dependency on the Curl library is dropped by adding support for the Httprl module and the native drupal_http_request. All these will have options to send purge requests one at a time. Curl and Httprl can issue requests in parallel. Httprl can issue nonblocking requests.

Documentation and inline help. (10% done)
Readme.txt should be updated, as well as the Project page, the Varnish documentation handbook pages. May end up adding advanced help.

Ideas for post 2.0 release:
- Dividing proxies in separate groups for purging at different levels of caching.
- Auto discovery of certain purge enabled platform. (doable for Acquia platforms)
- API for adding extra domains, headers and form elements for more platforms. (like fastly)

At this moment (late October 2012) the 2.x branch is non functional since most effort has been put into the gui. It's usability should improve over the coming weeks. I'll keep posting updates in this issue.
Please provide feedback in the comments of this issue or create a feature request.


Is there an update for 2.x? I haven't seen anything on the dev branch since May.

+1 on another update post, please. :)

+1.. would love to see support for the Httprl module and none blocking calls.

Sorry to keep you all waiting so long. It's been a wild year so far. Here's your long awaited update:
- 2.x is slowly getting into shape.
- Do expect large changes that break things on the configuration side of things so just for playing around and no production use yet....Will role and alpha release in the coming few days. This should contain:
- Fancy Admin UI section. Allows to set custom domains, headers, url's, methods etc.
- Using suboptimal database tables for configuration storage. (needs refactoring)
- API that allows for other contrib modules to (re)configure the module, add domain, headers and custom request handlers.
- Buildin request handlers for drupal_http_request(so slow and limited by design), curl(single,multi and a legacy multi version), httprl and guzzle.
- Optional watchdog logging.
- Silly example module for API integration at https://drupal.org/sandbox/sqyd/1963962

Todo still before Beta release:
- Simplify configuration storage.
- Add caching mechanism for active configuration.
- Provide more inline help, installation hints, advanced help integration etc.
- Update documentation.
- Apply for America's Next Top Module (tm)

Acquia specific Purging stuff will be handled by the Acquia Purge module. available at http://drupal.org/project/acquia_purge
The current 1.x branch of this module replaced Purge 1.x as the recommended way to accommodate your purging desires on the Acquia platforms.
Purge 2.x will provide the API that acquia_purge 2.x and other modules can use to build on top of Purge and provide zero conf and platform specific features. This way Acquia Purge 1.x will provide a sustainable upgrade path.