(Meta) Multiple updates in fork?

[totten]

This is a meta question. I work on a project that's been looking for a bower off-ramp and which gets used in several different file-structures. The approach in this plugin seems clever and like a pretty good fit. I've got some some usability improvements in a fork, but I also see the repo hasn't been updated in 2 years, so I'm not quite sure how to pursue publication -- e.g. whether to pursue a series of PRs or just keep the fork going.

Patch Queue

First, here's a preview of the changes:

• Root project support: I tried the plugin like so: create a new folder with a new composer.json, copy the example snippet, run composer install, and.... nothing. I figured it wasn't working. After poking/testing/reading more carefully, I found it does work... but only for dependencies. If the extra-files are in the root project (which is one of the cases that I do need to use), then it doesn't work. It's easier to learn/test/develop/iterate when one has root-project support.
• Tracking file: Suppose you locally edit the url of a file and re-run composer install. It doesn't do anything. The patch now uses a tracking file (.composer-extra-files.json) and re-downloads after any changes . I suppose it's not a big concern if you strictly consume packages (composer probably destroys the stale content in tandem with dependency-upgrade?), but it helps with learning/testing/developing/iterating.
• Ignore lists: Several of the upstream zip/tar files that my project pulls include dev/test/doc/experimental bits that shouldn't appear in the final build.
• Defaults (path, ignore): All the downloads in my intended project go under bower_components. It's handy to set the path with a default formula ("path": "bower_components/{$id}").

Details: https://github.com/totten/ComposerExtraFiles/commits/master

Approaches

I guess there are loosely two ways to go about this:

• Aim to publish a v1.1 or v2.0 of this plugin. Split out my patches into separate PRs for more discussion/review. The upshot is probably a higher-quality outcome (more insight/eyes/perspectives). However, it's more admin-work and regression-risk.
• Publish the fork under a different name. The upshot is less admin.