No, I ask why you use the P2D mode, since it doesn't work for you...
But of course, it is legitimate curiosity why it is problematic.
In 2.0b, P2D is OpenGL, so I suppose setting pixels repeatedly might not be perfect (OpenGL tends to shine in 3D but seems to have problems in 2D -- although I am far from being knowledgeable on the topic).

I can reproduce your problem with 2.0b7 so it seems there is indeed something buggy with P2D/P3D and the set() method. However using the pixel array directly is better anyway when setting large amounts of pixels. When you adapt the code to use the pixel array, there are no problems with P2D/P3D. Note that line 13 in your original code does nothing because you declare another local color c, besides it's not needed because the id starts as 0. Calculating the ix, iy and total number of pixels isn't needed either. The first two not, because you can use the index directly in the pixel array. The last because this is already a calculated number that you can get with pixels.length. See the adapted code below.

Adapted Code

1. int sz = 512;
2. int n = 1000;
3. int npoints;
4. color c;
5.  
6. void setup() {
7.   size(sz, sz, P2D);
8.   background(255);
9. }
10.  
11. void draw() {
12.   loadPixels();
13.   for (int i=0;i<n; i++) {
14.     int id = npoints % pixels.length;
15.     if (id==0) { c = color(random(255), random(255), random(255)); }
16.     pixels[id] = c;
17.     npoints++;
18.   }
19.   updatePixels();
20. }

Hi, You are right, I have no special reason to use P2D in this case, and I can also use pixels[].

Bugs can be reported in the Code section, ie. now the GitHub account.
Now, part of the problem might come from the fact that P2D uses smooth() by default (I think), so set() might do anti-aliasing, unlike the usage of pixels[]. Putting lot of anti-aliased items close of each other might result in some artifacts.