To my knowledge, Windows does not automatically adjust process priority.
Changing a process's priority sets the "base priority" of all of the threads in the process, and of all threads subsequently created within the process. (See my answer here for a description of this relationship.)
Windows does adjust the priorities of threads based on their recent activity. For example, after a completion of an I/O, a thread's priority will be boosted above its base by an amount determined by the function device driver for the device. Upon every timeslice end, if a thread is running at a boosted priority, its priority will "decay" by 1 until it falls down to the base priority. It does not decay below the base.
This is documented in the chapter on thread scheduling in Windows Internals by Solomon, Russinovich, Ionescu, et al.
But this does not match your reported scenario, because 1) the result of all this boost and decay of thread priority simply does not show up in Task Manager (since Task Manager reports process priority class, not thread priorities); and 2: this mechanism never decays a thread's priority below its base priority. The base is what is set when you change the process priority.
This may be something that Visual Studio (deveng.exe) is doing to itself. Do you see this happening to any other process?
This could be investigated with Windows Performance Toolkit.