It’s not a bug 
No, it isn’t, even if the double has 64 bit, it only uses 53 bits for precision, and that leaves us where we were with AppleScript, with 15 digits precsision. IEEE 2008 standard for floating point.
I am sorry for the blunder. 
Right. The whole point of using NSDecimalNumber in the first place was to avoid floating-point values – converting the result to a double threw all that effort out the window.
Just for information: The double double arithmetic still isn’t supported and long double is only 80-bit with an 63-bit significant value aka double extended precision. Also the 128-bit floating point also known as the quadruple floating point won’t be supported any time soon.
And for the interested ones: double double arithmetic differs from quad precision in significant and exponential value, the double double arithmetic does have an lower exponential and precision value in terms of bit size. That’s because 11 bits (from the second exponential double value) aren’t in use in a double double and an quad precision has a 15-bit exponential value . The significant value is 112- bit in the quad precision while it’s only 106-bit in the double double value. If we ever going to see quad precision data type in (Objective-)C I don’t know. The x86_64 architecture in the latest commercial PCs still only support long double (80-bit floating point; extended double)
Hello.
I guess one of the reasons for this is IOS. (I was just thinking about it, and thinks that the implementation of the NSDecimalNumber is a great way for achieving consistency among the platforms with different underlying Hardware architecture.)
Coming back to this, I think I now know the cause of these -4906 errors in AppleScript Editor: it’s autosaving kicking in. If you first click into another app to force an autosave, or perhaps even just save the document, they should disappear. In the other cases, autosaving is pulling a file from under AppleScript while it’s being used.
Nobody’s mentioned the Satimage.osax, so I guess I will. 
It is rather handy…
set pad to "00000000000000000000000000000000000000000000000000"
set n to "0000000000000000000000000000999999999999"
set nInc to format (n + 1) into (text 1 thru (length of n) of pad)
--> "0000000000000000000000000001000000000000"
set n to "0000000000000000000000000000999999999001"
set nInc to format (n + 1) into (text 1 thru (length of n) of pad)
--> "0000000000000000000000000000999999999002"
I was impressed when I saw all those zeros. But then I tried this:
set pad to "00000000000000000000000000000000000000000000000000"
set n to "0100000000000000000000000000999999999999"
set nInc to format (n + 1) into (text 1 thru (length of n) of pad)
-->0100000000000000000000000000000000000000
I suspect it suffers from the same limitations as the earlier solutions.
Ah, drat.
Oh, well. It works very well in the much shorter digit strings I usually encounter.