Simplify3d does have a bug in this along with plastic shrinkage. It's not just with round holes. I didn't check the GCode for outside permimiters, but for inside permimiters GCode is generated centered over the radius. With a .4mm nozzle and the fact layers are wider than nozzle size, you could see .8mm inaccuracies, even in plastics which don't shrink much as is the case I'm seeing. I started by generating a calibration cube with many different sized holes in it expecting to have to enlarge holes in my model by different amounts based on diameter. When I measured each one, from 3mm to 22mm in .5mm increments, each was off by roughly .8mm! No difference in the larger holes. That's when I went to the GCode and found the problem. Then tested a 4mm square hole cut out of a calibration. Cube. 3.2mm! So no, simplify3d needs to treat inner perimeters as boundaries, not as the point at which to move the tool head!
Really frustrating since I've been using simplify3d for everything. All my new spools are dialed in in simplify3d. Was trying to fix a massive overextension in skein forge in ngen and couldn't seem to get the numbers low enough. After 10 calibration cubes with unsatisfactory finished I decided I'll just drill the damned holes. Stupid to use subtractive after additive but with the bug, what else can be done?
Ill work later on putting together a bug report with test cases, GCode highlighted, etc. this isn't a question as to whether the bug exists. It's there. 100% repeatable, unlike my previous reports. (Not sure how there are such intermittent bugs, but I know the pain of hunting them!). After finding many of my reports were like that, I started restarting simplify3d every time it did something that seemed like it was an obvious oversight! This one is not one of those though. Pretty cut and dry, easy to reproduce, easy to fix, etc.