I've experienced the crafting lag you speak of. I've tied it, by repeated testing, to the crafting process and in particular the make max function. Indeed, the longer you craft, the worse it gets. Closing the client to clear RAM seems to solve the issue (the amount of RAM being used shows a definite slope upwards while crafting, then resets to a reasonable level upon reboot of UO).
But, I've also experienced something even more annoying, and unfortunately it is not tied to crafting and seems to be present at all times, but is far worse during peak hours--I think it is tied to the Comcast related lag everyone has been experiencing. What happens is that the time it takes for the client to recognize an item on cursor mouse-over and highlight/tooltip seems to be taking way longer then it used to. What this means is you have to actually wait up to a second to left click before you can drag an item (or get the tooltip). To make matters worse, once you do start dragging the item sometimes the shift modifier doesn't apply, which leads to dragging the entire stack instead of being given the split-stack gump.
I've based the assumption that this is somehow tied to the Comcast lag on the fact that it seems worse during peak hours--the same times I can do a trace and see that lag on ALTER.NET routers.
But here's the weird thing--I don't experience this problem in the 2D client. While I still get the "run/pause/run/pause/run" of the Comcast lag in the 2D client, I do not get the mouse/item issues like I do in the EC.
Pinco, there is a "Run mouse in separate thread" mode in the 2D client--Do we need something similar in the EC? It seems to me that both issues might be solved by doing just that--run the mouse in another thread. Is that possible with the EC and LUA, or would it be something that the Devs would have to implement through the .exe?