I cannot reproduce on Win 10, 32bit repository debug builds, amd64 machine, with either current master or 3.8, started from command prompt in normal environment with same command.  I also used installed 3.9 a bit.

Are .pyenv and pyenv-win your names or do they mean something possibly relevant?  I presume PS is PowerShell, which should not be relevant.
Did you get the stack trace upon startup, or thereafter, without touching the app?  If not, what did you do, in detail?

One time crash or repeatable?  Either way, please try current release.  If we cannot reproduce, we cannot test a fix. 

In the stacktrace, each cycle begins with a mouse-move event, handled by eventfun, which wraps and calls the user function (here 'shift) with event.x, event.y.  The relevant code is

    def shift(self, x, y):
        self.sety(max(0,min(y,1)))
        self._color[self.x] = self.ycor()
        self.fillcolor(self._color)
        setbgcolor()

def setbgcolor():
    screen.bgcolor(red.ycor(), green.ycor(), blue.ycor())

Both sety (move turtle to y) and bgcolor require an update __call__ into tcl/tk.  These normally should return and the call stack back to eventfun unwound.  Instead, it appears that new event handlings get added.  I suspect something peculiar about your system.

The line  'File "<string>", line 1 in coords' is extremely odd, as it looks like an interactive injection of a command.  However, the previous trace line is '...turtle.py", line 755 in _pointlist', referring to turtle line

        cl = self.cv.coords(item)

where cv is a tkinter canvas, and the 2761 in the top trace is the line within the coords methods calling tk.  So maybe <string> is an anomaly related to stack exhaustion.

Another possible factor is the turtle _items list.  It can grow, but I am not familiar with turtle internals.