Following the decision to change the grammer to:

[172]        FTThesaurusID        ::=        "at" URILiteral 
("relationship" StringLiteral)? (FTLiteralRange "levels")?

[new]        FTLiteralRange     ::=        ("exactly" IntegerLiteral)
| ("at" "least" IntegerLiteral)
| ("at" "most" IntegerLiteral)
| ("from" IntegerLiteral "to" IntegerLiteral)

the question regarding restriction xs:integer is no longer relevant.

The following XQuery functions offer a description as to how thesaurus option levels could work.  They assume the format of thesaurus used in XQFTTS.

Negative levels are normalized to 0.
Ranges from $n to $m where $n > $m is normalized to $n to $n.

declare namespace t = "http://www.w3.org/2007/xqftts/thesaurus";

(: Helper funciton.  Expand each word in words exactly one level :)
declare function local:expand-one-level($words as xs:string*, 
                                        $thesaurus as node(),
                                        $relationship as xs:string)
                 as xs:string*
{
  distinct-values(
    $thesaurus/t:thesaurus/t:entry[t:term = $words]/t:synonym[t:relationship eq $relationship]/t:term)
};

(: Helper funciton.  Expand each word in words exactly $n levels :)
declare function local:expand-n-levels($words as xs:string*, 
                                       $thesaurus as node(),
                                       $relationship as xs:string,
                                       $n as xs:integer) 
                 as xs:string*
{
  if ($n eq 0)
  then $words
  else let $expansions := local:expand-one-level($words, 
                                                 $thesaurus,
                                                 $relationship)
       return local:expand-n-levels($expansions, 
                                    $thesaurus, 
                                    $relationship, 
                                    $n - 1)
};


(: Helper funciton.  Constrain level values to be non-negative integers :)
declare function local:constrain-level($level as xs:integer)
                 as xs:integer
{
  if ($level lt 0) 
  then 0 
  else $level
};

(: Helper funciton.  Repeatedly expand $words until a fixed point is reached :)
declare function local:expand-to-infinity($words as xs:string*, 
                                          $thesaurus as node(),
                                          $relationship as xs:string)
                 as xs:string*
{
  let $next-level := for $word in $words
                     return local:expand-exactly($word,
                                                 $thesaurus,
                                                 $relationship,
                                                 1)
  let $expansion := distinct-values(($next-level, $words))
  return if (count($words) eq count($expansion))
         then $words
         else local:expand-to-infinity($expansion,
                                       $thesaurus,
                                       $relationship)
                                    
};

(: Expand $word exactly $n levels :)
declare function local:expand-exactly($word as xs:string, 
                                      $thesaurus as node(),
                                      $relationship as xs:string,
                                      $n as xs:integer) 
                 as xs:string*
{
  let $level := local:constrain-level($n)
  return local:expand-n-levels($word,
                               $thesaurus,
                               $relationship,
                               $level)
      
};

(: Expand $word from $from to $to levels :)
declare function local:expand-from-to($word as xs:string, 
                                      $thesaurus as node(),
                                      $relationship as xs:string,
                                      $from as xs:integer,
                                      $to as xs:integer) 
                 as xs:string*
{
  let $lower := local:constrain-level($from)
  let $upper := max(($lower, local:constrain-level($to)))
  return distinct-values(for $level in $lower to $upper
                         return local:expand-exactly($word,
                                                     $thesaurus,
                                                     $relationship,
                                                     $level))
};

(: Expand $word at most $n levels :)
declare function local:expand-at-most($word as xs:string, 
                                      $thesaurus as node(),
                                      $relationship as xs:string,
                                      $n as xs:integer) 
                 as xs:string*
{
  local:expand-from-to($word,
                       $thesaurus,
                       $relationship,
                       0,
                       $n)
};

(: Expand $word at least $n levels :)
declare function local:expand-at-least($word as xs:string, 
                                       $thesaurus as node(),
                                       $relationship as xs:string,
                                       $n as xs:integer) 
                 as xs:string*
{
  let $initial := local:expand-exactly($word,
                                       $thesaurus,
                                       $relationship,
                                       $n)
  return local:expand-to-infinity($initial,
                                  $thesaurus,
                                  $relationship)
};

(: Expand $word when no range expression specified :)
declare function local:expand-default($word as xs:string, 
                                      $thesaurus as node(),
                                      $relationship as xs:string)
                 as xs:string*
{
  local:expand-at-least($word,
                        $thesaurus,
                        $relationship,
                        0)
};

If this stuff gets accepted into the spec now, I'm wondering why this stuff apparently wouldn't send the spec back to the "Working Draft" stage, yet a fix to the AppleFT*Window semantics (bug #12144) would according to comment #7 on that bug.

Paul, it's both a matter of degree and a matter of incompatibility.  In addition, it's a matter of original intent. 

First, the decision to change the BNF to require an integer value instead of a generalized expression is compatible with implementations that allow a generalized expression, which can be treated as an implementation extension. In addition, it's a very small change to the spec that does, in fact, reflect real-world usage patterns and the original intent of the spec authors. 

By contrast, the syntax and semantics discussed in Bug 12144 were heavily discussed and debated before settling on what is currently in the specs, which implies "original intent".  The change that you would like, and that we've agreed to consider in a future version of the FT spec, would require a more significant change to both the syntax of the language and to the semantics thereof. It would also invalidate all implementations that have already implemented the spec as currently written. 

You should know that we agonized for a long time before concluding that the change for this bug was justifiable before going back to working draft.  The points in the second paragraph of this comment were sufficiently convincing. 

Hope this helps!

As pointed out in comment #1, the matter re conversion to xs:integer is no longer relevant. At its meeting yesterday, the XQuery WG decided to address the remainder of this issue as follows:

(a) Add a paragraph to the FT spec:
"The effect of specifying a particular range of levels in an FTThesaurusID is implementation-defined. This includes cases involving empty ranges, negative levels, or levels not supported by the thesaurus."

(b) Add prose to the FT Test Suite instructions, reflecting whatever of comment #2 is needed for running the test suite.

I am marking this bug resolved-fixed. Tim, if you agree with this resolution, please mark it closed.