APPEND/PART refinement clips output if shorter than input block

[hostilefork]

There is a controversial interpretation of the /PART refinement on APPEND and INSERT which says that it refers to an integer length of how many units of the result series type should be used.

#2096

However, R3-Alpha doesn't quite heed this rule. It uses the length of the source series to clip that limit:

r3-alpha>> append/part "abc" ["defg"] 2     
== "abcd"  ; because the overall block is only length 1, it is clipped

r3-alpha>> append/part "abc" ["defg" "hijk"] 2
== "abcde"  ; increasing the block size changes this around

This comes from a call to Partial1() which takes the source argument in the A_APPEND and A_INSERT case, which it then uses to make the clipping decision. Under the current stated rules of the game, it doesn't know where to clip, so it needs to leave that decision up to Modify_String().

Moreover, it probably should only accept an INTEGER!...as taking series positions for a /PART under this rule do not make sense! Red has that problem as well:

red>> append/part "abc" x: [100 "de" "fg"] next next x
== "abc10"

But it doesn't have the problem with the length clipping:

red>> append/part "abc" ["defg"] 2
== "abcde"

red>> append/part "abc" ["defg" "hijk"] 2
== "abcde"

Though it does seem to interpret negative numbers in a nonsensical-seeming way:

red>> append/part "a" ["bc" "de"] -1 
== "abcde"

red>> append/part "a" next ["bc" "de"] -1 
== "ade"

red>> append/part "a" next ["bc" "de"] -2
== "ade" 

[Oldes]

Is there any proposition what should be results for above cases?