The following nine SRFIs passed with resounding majorities:  

SRFI 115 (combinator-based regular expressions)

SRFI 141 (comprehensive integer division operators)

SRFI 143 (fixnum operators)

SRFI 144 (flonum operators, R6RS plus <math.h>)

SRFI 146 (persistent tree and hash mappings)

SRFI 151 (comprehensive bitwise operations on integers)

SRFI 158 (backward-compatible additions to SRFI 127 on generators)

SRFI 159 (combinator formatting)

SRFI 160 (comprehensive homogeneous vector library, including inexact-complex vectors)

The sample implementation of SRFI 160 is not yet written: however, the API has mostly stabilized, excluding u1vectors (bitvectors) from consideration and adding a (srfi 160 base) library that provides SRFI 4 support for all SRFI 4 vector types plus the complex types.

The R6RS library (rnrs bytevectors) was adopted into Tangerine, also by a large majority.  Implementors should note that "must" when applied to a procedure or macro argument means only "it is an error unless"; actually signaling an error is not required.  In addition, there are corrections at <http://www.r6rs.org/r6rs-errata.html>, including substantive changes to the `utf16->string` and `utf32->string` procedures.  A portable R7RS-small implementation of this library written by Will Clinger can be found at snow-fort.org and in the contrib/cowan subdirectory of the SRFI 4 repository.

Required support for the full numeric tower, including bignums up to an implementation-defined limit, ratios (exact non-integers), inexact numbers, and complex (non-real) numbers both exact and inexact, is also part of Tangerine. There are no such requirements in R7RS-small. Note that while most numeric types were uncontroversial,  exact complex numbers passed by just one vote.  (See  <http://mentalfloss.com/article/59873/10-elections-decided-one-vote-or-less> for other elections decided by a single vote.)

Finally, the vote on the string library was problematic.  Out of 26 votes cast, a one-vote majority of 14 voted for SRFI 152, a simple index-based string library.  However, rather than accepting the Will of the People in this particular case, your Chair has decided to disregard this vote and postpone the choice of a string library to the Green Edition.  Anyone who wishes to appeal against this decision should post to <scheme-reports-wg2@googlegroups.com>, and if anyone does, a vote will be taken on that list whether to sustain the Chair's decision (no string library yet) or override it (SRFI 152 becomes the string library).

Why am I doing this?  There were 6 votes for the original SRFI 13, of which SRFI 152 is a subset.  There were 3 votes  for the cursor-based SRFI 130, which its author has offered to rewrite (as a new SRFI) to remove some substantive objections to it.  SRFI 140, which splits Scheme strings into mutable and immutable subtypes, also received 3 write-in votes: I had excluded it from the ballot because it cannot be portably implemented on top of R7RS-small, and non-portable SRFIs are collected in the Green Edition.  For that reason, string libraries will be revoted then.  (In the Red Edition, no proposal obtained a majority.)

As is traditional, the Chair is giving the new libraries their official names.  The names corresponding to the SRFIs in the order listed above are:  (scheme regex), (scheme division), (scheme fixnum), (scheme flonum), (scheme mapping) and (scheme mapping hash), (scheme bitwise), (scheme generator), (scheme format), and (scheme vector @), where @ is a metasyntactic variable for any of {base, u8, s8, u16, s16, u32, s32, u64, s64, f32, f64, c64, c128}.  The (rnrs bytevectors) library will be known within R7RS-large as (scheme bytevector): note the change from plural to singular to conform with other R7RS library names.

The (scheme mapping hash) library has fewer operations than the (scheme mapping) library, but is usable with unordered data types provided a good hash function can be written for them.

This decision supersedes within R7RS-large the Red Edition's definition of (scheme generator) as SRFI 158.  This should affect nobody except people who have used one of the 19 new identifiers for some other purpose, in which case import exclusion is at their service.

Of the nine libraries asked about on the Orange Edition straw poll, all were well-supported (with volunteers to implement some of them) except the prime number library at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/PrimesGauche.md>.  There was also a one-vote majority against the TalliesCowan (descriptive statistics) library, but as there is a volunteer to implement it, I'll leave it on the docket for now.

--