… the trouble being they have been outstanding for a while now 
As they have been PRs on the swift-evolution repo for a while now I’d like to stir the pot one more time to see if there is any appetite in the community to bring them to review seeing while there is a bit of a lull on S/E before the implementations get stale.
Accept Values for Custom Compilation Flags
Pros: This is a niche feature but when you need it there are very few alternatives available at present. It also has a bonus feature of being able to include a raw files to initialise a String as discussed in other threads.
Cons: There is a school of thought that this would be an anti-feature where some sources would require additional Xcode configuration/command line options to build though the proposal provides for providing defaults.
Single Quoted Character Literals
This is the rump of the much discussed Caharcter literals threads breaking the proposal up into two parts as suggested by the core team. The first (less contentious proposal) is to change Characrer and Unicode Scala literals to have their own single quote delimited syntax with a fixit for migration. At a later date perhaps this new syntax could be used to make available a convenience notation for ASCII literals but this would not be discussed at this stage in the interests of convergence.
Pros: A single quoted syntax distinguishing between String and Character literals would bring Swift into line with other commonly used languages and make explicit the contexts when a character literal is being used making code clearer. Whether this add to the mass of the Swift language that has to be leant by a newcomer is unclear as they would typically becoming from a language that makes this distinction. While the proposal has already had its place in the sun it has elicited 900 posts so there some evidence people like tat least to discuss it.
Cons: why change an existing language feature that works well and introduce a source breaking change so late in the day? The syntax could be optional and produce a warning for the foreseeable if this is seen to be a problem. But then again enough already…
Collection conditionals SR-8743
Pros: This would be useful allowing condition inclusion of collection elements dependant on build configuration useful for debug builds or testing on different architectures.
Cons: This proposal met a bit of a sticky end with the patch being rejected before it went to review as it complicated the AST but I’d like to keep the idea alive. The problem is it falls in the cracks between this who could like to implement conditionals as in the lexer as a preprocessor function and those who would like to see a residue in the AST for other purposes such as code generators etc.