You likely aren't surprised by this:
r3-alpha/red>> append/part [abc def] [ghi jkl mno pqr] 2
== [abc def ghi jkl]
You asked for 2 units of the appended value's /PART, so you just got [ghi jkl] out of the spliced (by default) block.
But is this what you expected?
r3-alpha/red>> append/part "abcdef" [ghi jkl mno pqr] 2
== "abcdefgh"
To me that runs counter to the idea of what /PART is supposed to mean. (Not to mention, it doesn't seem all that useful.)
We've fancifully talked about /PART being something that would be encoded as a property of lists, e.g.
>> part [ghi jkl mno pqr] 2
== **[ghi jkl]** ; special lightweight "view" on list
If this were the case, then we might rewrite append/part "abcdef" [ghi jkl mno pqr] 2 as:
append "abcdef" part [ghi jkl mno pqr] 2
In which case we would expect that to act like:
append "abcdef" [ghi jkl]
Not append "abcdef" [gh].
What Red and R3-Alpha are really doing are more like:
append "abcdef" (part stringify [ghi jkl mno pqr] 2)
Where STRINGIFY in this case isn't any well-known operation. It's not FORM (because there's no spaces), it's not REJOIN or AJOIN (it doesn't reduce). The only real definition of it would be "what you get when you append a block to a copy of an empty string." 
Ren-C Now Uses A Consistent Interpretation
>> append:part [abc def] spread [ghi jkl mno pqr] 2
== [abc def ghi jkl]
>> append:part "abcdef" spread [ghi jkl mno pqr] 2
== "abcdefghijkl"
>> append:part #{ABCD} spread [#{12} #{3456} #{78} {9000}] 2
== #{ABCD123456}
It always speaks about the length in terms of the value you are appending. If the value isn't a splice or series, I think it should probably be an error (though I haven't enforced this yet...)
>> append:part "abcdef" 1020 2
** PANIC: PART can only be used with series or splices