@compton - The solution you proposed is definitely a viable solution, but I think it is closer to Option 1 rather than 2 as you are still going to check in your vendor directory in your primary repo.
Perhaps it could become policy that contributions be merged as a squashed commit for non-vendored code alongside a second commit which includes additions/modifications to the vendored code.
My understanding is that you are proposing squashing commit to primary repo code + dependency commit whenever there is an update to both, right? A while ago I came across this blog post (Git: To squash or not to squash? // James Cooke // Brighton-based Python developer) which has interesting insights about squashing git commits. This might not be completely relevant but it does clearly convey that squashing is a somewhat complicated approach. That said, I will definitely explore your proposed solution in future as it might help keeping the git log clean, but at this point we should start with a simpler approach.
As mentioned in my previous reply, I want start with Option 3 now and then we can come back to this conversation later after considering other approaches.
I will open up a PR request in a day or two.
@mrjn - The process explained in those slides seems to be a good fit for open source projects as it encourages community involvement and interest. Thanks for sharing them.