1. We have something in this direction already in the form of "guest users" that can be added to your boards and don't count as a seat. They currently have full privileges on the boards they can see, though – our permissions model isn't fine-grained yet.
2. Sounds like we may need to improve our description of this feature, but right now, we're optimizing for small-PR "trunk-based dev" [1] workflows where a ticket can have several PRs, but a PR always maps to a single ticket. We push the ticket info onto PRs in GitHub so code reviewers don't even have to click through to Constructor to get the context they need to do their review. We'll definitely support use cases like yours in the future, though!
We were spun off a consultancy and use it with all our consultants clients.
PM me for more information!
1. We need to give clients access, and we need to give those clients fairly fine grained control - ie: This user can see the tickets, move them around, comment etc. but not close them. On some projects we have lots of people on the client side that want to be able to see the tickets, so we very much don't want to have to pay per user for client access. For many reasons, giving them GitHub access is not ideal, but the biggest reason is that GitHub's permissions model on issues is, at best, bizarre.
2. I got quite excited when I saw the words "bidirectional GitHub integration" on the home page, but then I read the description underneath and I'm having a really hard time picturing what it does. We like adding ticket numbers to commits, because that keeps a reference to the change that was made in the ticket thread on GitHub. Other devs coming in can easily read the thread and click through to see the change. Your description of the GitHub integration seems very focussed on PRs rather than tickets, and the way we work a PR is most likely to contain many, many commits, and multiple tickets.