Hey Chris! Some answers below:
A nit about the proposal is "We could optionally provide". For clarity, it helps if the proposal would state one clear opinion about what is being proposed, instead of offering up multiple design points. Alternates can be discussed in the "alternatives considered" section.
Note taken. It's my personal preference that we include all three proposed functions, but I know some members of the core team feel differently and I don't want my proposal to read like it's trying to shut down that discussion. 
With respect to the new builtin, does this generate the llvm.lifetime.start/end intrinsics ?
The implementation will generate them, yes. As of right now the implementation branch is definitely generating incorrect IR.
Is this enough to provide a new Array initializer that puts its elements on-the-stack ala
llvm::SmallVector?
As discussed in the pitch thread, encapsulating a temporary buffer like this in a value triggers the need for escape analysis, which often prevents stack promotion. The scoped with functions avoid that issue by explicitly defining a lifetime for their temporary buffers.
I think we should eventually discuss how we're going to un-pyramid-of-doom the with style methods, but that is definitely orthogonal to this proposal.
Agreed. Please ping me if you get that discussion going!