You know what other graphics programs do differently to fix this problem all at once from the top down?

I stopped and checked my other favorite paint program to see how it handled this general focus issue.  Gimp captures tab, enter and space in dialogs, same as Inkscape.  With the same dangers.  Use the crop tool to select an area, but before clicking inside or hitting enter select the resize view widget in the status bar.  Enter 33 and like before don't press enter.  Hover the mouse over the crop area, press enter => the window resizes to a 33% view.  Press enter again => window is cropped.  Reverse the order by entering a view % number first then creating the crop box and the first enter crops, the second resizes.  And until pressing enter  or touching something else with stylus all numbers are grabbed by the view size widget.  

They don't do anything differently to fix this problem all at once from the top down.

But they don't have this problem.

Opinion.  This isn't as large a meta issue as you assume.  People are used to a little focus confusion between the mouse and keyboard in a GUI.  I think the problem is poor execution in creating the specific dialogs in question.  The specific problems you've mentioned above have been problems for a very long time now.  I don't think there is an awesome general fix coming.  Only more user frustration with these long standing annoyance bugs.

The box that accepted 'n' in for width zero in the stroke-fill dialog should pass along everything but digits, and it shouldn't come up highlighted and ready for entry right when you select the tab, the user might only be checking the info there, or maybe he opens that dialog every time he starts a new image.  The layers dialog is just bad.  There is a totally useless function that grabs alphanumeric keys (s is grabbed, ctrl-s goes through and opens a save dialog) without any visual indication that it is going to do so.  Similarly the type ahead find in the effects list, such a function in a non-modal box might just not be doable at all, in a main window sure, or after you click in a 'search' or an 'effect name' entry box and a obviously different and important box traps your keyboard sure, but not the way it's implemented (it's not a 'the way you coded it' problem, it's a 'what you tried to do in the first place' problem).

Short term solution:  (All that's really necessary)
Just fix the worst offending dialogs.  Others should just be changed as problems arise or in the natural course of other fixes and updates.  If at all.

*Long term solution:  (Who cares?)  
This is only a problem in a few very select areas but I've included one at the bottom if you're interested in my long winded rants.

DS

*Long term solution: (To prevent recurrences in other areas.)  

Follow proper GUI expected behavior for non-modal dialog boxes and tool bars.   No key entry of data until the user clicks or tabs to the entry point (not just the dialog in general) and it is redrawn appropriately to make it obvious (no instant on keyboard focus to some data entry box when the dialog first opens).  Only 'tab' (and it's shift and ctrl variants) and 'enter' can be captured immediately on focusing a dialog box.  Pressing 'enter' immediately on opening the dialog box should just activate the 'apply' button (the non-modal equivalent of 'Ok' button)  if there is one and that apply button should be the LAST button on the box.  Pressing 'tab' first should wrap input focus around from from the 'apply' button to the first item in the tab list.  If there is no 'apply' button pressing 'enter' or 'tab' first should act like pressing 'tab' if there were a final 'apply' button, that is wrap focus around to the first entry field and highlight it.  Once focused with 'enter', 'tab' or clicking, keyboard focus should not be given to the control until it looks suitably like it is ready for it, turning the whole row blue is NOT enough if there are non key board focus reasons for turning it blue.  Right when focus is switched, the box needs to change to an obvious text entry box (it can still be 'in place') with a noticeably different box drawn around it, a blinking cursor, and previously entered or default data highlighted in blue.  Buttons should get boxed up in that grabbing the space bar or enter key fashion we're used to.

The 'tab' and 'enter' keys themselves are unavoidably going to be a source of occasional confusion.  It might have been best not to have used them at all for tools that work on the canvas.  There are no 'ok' and 'next item' keys, and it's plagued GUI's since Xerox invented them.  But users are wary of these two keys.  And the instant change to a obvious keyboard focused condition on the other controls should limit the confusion to only those two keys.