In a way, it is silly now to have this particular createTupleSchema overloaded signature. We always need to use the other overloaded signature in the actual product code to support BYTES, so this overload (and all the other other overloads) are really here for "test support only". If we are going to change all the calls in the tests to drop the useless boolean, I would go ahead and change the NAME of this function too, something like "createTupleSchemaForTest". I think it's confusing to have to count arguments to tell whether you mean the test-only method.  If you do not want to change the function name for the test-only method, I would say "then why not keep the whole thing backward compatible?" KEEP the silly boolean -- at least now the boolean argument has the benefit of making the "test only" factory method easier to distinguish from the "production" factory method. 

Ideally, I would not use overloading at all here and I would give each createTupleSchema factory function a specialized name: createTupleSchema (the normal one), cloneTupleSchema (the one that acts like a copy constructor, also used in the product -- AND I would make that a non-static member function of the original TupleSchema), concatenateTupleSchemas (for the one that takes two existing input schemas), and truncateTupleSchema (another one that could be a member function -- that clones part of an existing tupleSchema -- and the signature on this one could be greatly simplified because it is ALWAYS used to clone the first N columns of the larger schema and never needs to skip a column in the middle). We don't have to make all these changes now, but since we are changing TupleSchema.h, I would at least consider adding comments there about which signatures are product code and which are test-support only, and maybe add "TODO:" comments about our plans to eventually rename each of them.

Short term, I wouldn't mind if all the test-only methods used their old backward-compatible signatures.
And I wouldn't mind if they all asserted that they were not using inBytes (instead of pretending to propagate this option).

On the other hand, we should have at least one dedicated EE test case that directly uses the production factory method to exercise some inline and non-inline use of VARCHAR w/ BYTES, even exercising the Too Narrow error code paths.