againey

Yup, that appears to work just fine for me, no crash. Same with basic Paste or Paste into New Layer. Only by opening the New dialog and then doing something like typing a number into one of the boxes, clicking an up/down arrow, clicking on a dropdown box, or the Cancel button. Curiously, clicking the OK button causes no crash, but successfully creates a new image with the correct dimensions.

Same here. Neither Firefox nor Chrome crashed. And I couldn't get the crash using other dialogs or commands like Resize, Canvas Size, or or Paste Into New Image. Only the New dialog produced a crash. Crash log:

I was unable to reproduce the issue. The only way I could cause the crosshatch background to show up was if I selected and moved without performing a copy+paste. If I selected, copied, pasted, and then moved, it always moved the copy and left the original intact, generating no open rectangle. As a side note, to move a selection, your cursor doesn't have to be inside the selection. Anywhere outside of the selection area works fine too, as long as you're far enough away from the rotation/stretch handles.

Turns out, no it didn't work in 3.5. I just uninstalled 4.0 and installed 3.5.11, and nope, the trackpad's horizontal movement still doesn't produce horizontal scrolling. BoltBait's suggestion to hold the shift key did translate vertical trackpad movement to horizontal scrolling though. Sorry for the earlier fire-and-forget report and consequent delay in responding.

Borderline bug/feature request: Horizontal scroll wheel doesn't seem to be recognized. I'm using a trackpad that supports two-finger dragging to simulate the mouse wheel, but paint.net only recognizes vertical movement. Other applications like Firefox or Windows Explorer will honor both vertical and horizontal movement as expected, so the drivers seem to be functioning correctly. I don't have a mouse/trackball device with a physical horizontal scroll wheel to test with, though.

The pixel grid always goes away when switching between two different images. And since there's no keyboard shortcut, it's been a bit of a burden having to re-enable it frequently. Open or create two images, and zoom into both 400%. While viewing the first image, turn on the pixel grid from the view menu. View the second image by selecting the thumbnail at the top. Now go back to the first image by selecting its thumbnail. Pixel grid is turned off. I've also had some hard-to-describe/reproduce issues with my laptop's trackpad. It kind of feels like unusual interactions between the trackpad driver's delay for determining how to interpret the incoming data, and paint.net's new asynchronous behavior. But it might be purely due to the drivers, and so unfixable within paint.net. And a trackpad is not an ideal input device for a paint program anyway, so I need to just buy a mouse and move on. But for reference's sake: For example, switching to a different tool using the keyboard shortcut and then tap-clicking or double-tap dragging really quickly after the key press sometimes fails to register the trackpad action. I have to pause after switching tools. Another one I recall involved a few clumsy moment where I clicked on a dialog (the color dialog I think), but then quickly and accidentally dragged out over the canvas, and since I had the line tool selected, paint.net decided to draw a line from my starting point under the dialog to my ending point out in the exposed portion of the canvas. It seemed like the UI didn't do an immediate hit test to determine which UI element was clicked, but instead delayed the hit test (perhaps the driver's doing), but paint.net still knew the starting position somehow. Everything else I can think of right now falls into feature-request territory, so I'll let those simmer.