I’d stick with 1, mostly because of the drawbacks of 2 (link).
As the project evolves, I bet that you’ll have some overlap. And when (and if) that comes, I’d rather that barrier be a small one rather than a larger one. I’m not great at seeing the future though, but I’m also transparent that I don’t know it… 
. With these decisions, it’s usually good to defer the decision by choosing something trivial to reverse. Options 1 allows you to do option 2 or 3 or 4 later on, while option 2 and above don’t allow you do go back to option 1 trivially.
I’ve yet to see a better approach than using contexts with discipline (in short, everything goes through a context module). There are some tools that make it a tech barrier rather than an administrative one, but I have found that if leaning on the administrative one (discipline, having good conversations/discussions, sharing approaches) yields better returns later on, not just in code, but everything on the team.
Please report back when this is done, I’m sure you will have lots of takeaways and we can all learn from it. Congrats on the success! 
