Having concepts like CHAIN! means there are "set integers" now, which has opened up the possibility for things like:
sub1000: specialize subtract/ [2: 1000]
This would prevent you from having to specifically know the name of the argument you are specializing. That seems sensible, given that you don't need to know the name to call it.
It seems you should also be able to do this with frames:
>> f: make frame! subtract/
>> f.1: 1020
>> f.2: 1000
>> eval f
== 20
It should not work with refinements. Rebol2/Red/R3-Alpha expose the implementation detail of what position refinement arguments are in, but it was a bad idea for them... and an even worse idea for Ren-C.
Consider AUGMENT, for example. Let's make an arity-3 version of APPEND, that takes an argument to add before appending:
>> apadd: adapt (augment append/ [num [integer!]]) [
value: value + num
]
>> apadd [a b c] 1000 20
== [a b c 1020]
Do take a moment to appreciate how cool that is... AUGMENT creates a function with an expanded specification (but no variation in behavior), and then ADAPT puts in a preamble which uses the added parameter by adding it to the value...before falling through to the ordinary implementation of APPEND. (ENCLOSE could be used if you had a more complicated idea for what to do that didn't fit as just an adjustment in a preamble.)
BUT once you're finished appreciating how cool that is, consider what we want if we make a frame for APADD:
>> f: make frame! apadd/
>> f.1: [a b c]
>> f.2: 1000
>> f.3: 20
>> eval f
== [a b c 1020]
However, consider that it also has refinements available:
>> apadd:dup [a b c] 1000 20 3
== [a b c 1020 1020 1020]
So we see that the new non-refinement argument properly indexes as the 3rd argument, and it could not do that if refinements were INTEGER!-indexed. Because if :DUP was something like index 3 in the frame for APPEND originally, it wouldn't be out of the way of the augmented form.
Seems pretty good, but there are some quirks...
Lens Matters
I've written a bit about FRAME! Lensing. It's not just an efficiency trick...because I wouldn't know how to implement function composition otherwise.
Because of Lenses, a frame built for a function with the same positionality can expose different interfaces. Consider our APADD above, imagine specializing the thing you append to:
>> data: [a b c]
>> accrue: specialize apadd/ [data]
>> accrue 1000 20
== [a b c 1020]
>> accrue 300 4
== [a b c 1020 304]
So now, we would hope that ACCRUE thinks of its 1 and 2 parameters as being what APADD thought of as 2 and 3.
>> f: make frame! accrue/
>> f.1: 400
>> f.2: 21
>> eval f
== [a b c 1020 304 421]
Satisfying!
But What Does Integer Indexing Mean With No Lens ? 
There's a point where all the Lenses are gone, and you are in the raw function implementation... the FRAME! as the underlying implementation expected to see it. If you do a FOR-EACH on a frame in this view, you see everything.. refinements, locals, definitional RETURN (if there is one).
>> foo: func [arg1 :refine1 arg2 :refine2 <local> local1] [
let frame: binding of $arg1
for-each 'key frame [probe key]
]
>> foo 1020
return
arg1
refine1
arg2
refine2
local1
What (if anything) does indexing mean at this level? frame.1 giving you back the definitional RETURN would be barely useful... probably even anti-useful.
I think it's pretty clear the integer indexing on an unlensed frame should act as if you were seeing the frame from the perspective of a caller with the "default Lens", e.g. what someone who did MAKE FRAME! would see.
So frame.1 would give you arg1, and frame.2 would give you arg2, and that would be it.
Should OBJECT! Offer Indexed Access?
I've settled that FRAME! should offer it. Here we see it has the interesting consequence that not all frame fields can be accessed with integer indexes, only
But I don't know what--if anything--this implies for OBJECT!.