@Carl Love Let's suppose that there theorethically exists a symbolic solution S such as you seek regardless of our ability to find that solution. So, I mean "exists" in the idealized Platonic sense. Then S could easily be used to generate any numeric solution N. But, of course, there are numeric methods that could be used to find an approximation to N (without knowing S) that use much less computation. If you can't find any suitable numeric solutions, then IMO it's a waste of effort to search for S. So, look for approximate numeric solutions first.

@MaPal93 I just reread this entire thread, and I noticed that you never really answered my first question: Why do you think that there's a solution? And what makes you think that the computation is "stuck" rather than proceeding in a correct manner with a very lengthy process?

I haven't yet looked at your most-recent attachments.

@sursumCorda It's not strange at all. There is no bug in `simplify/sqrt/function`. An error message tells you what procedure was executing when the presence of a bug (from any location) was detected. It doesn't tell you where in the code the bug is.

@C_R The OP's title suggests (to a small degree) that they believe this to be a Maple 2023 new bug.

There's no need to use $ in any form; F~(list1, list2) works fine.

@zenterix Maple's 2D plot command has some fairly sophisticated options (discont, fdiscont) for handling discontinuities. These can use both symbolic and numeric techniques, and I think better results are usually achieved symbolically. As far as I know, there's nothing like that currently available for 3D plots.

Larger grids generally provide "diminishing marginal returns". In other words, one quickly gets to a point where the plot's improvement isn't worth the additional computation. Using a 1000x1000 grid for this plot means 24-million numeric values computed, which is likely above your display's resolution. Maple's kernel can easily handle the initial computation of these, but the GUI has trouble moving and positioning them.

@acer As is usual with Maplesoft, the absence of any official response is quite disturbing. Even an official response just saying "We are aware of the existence of the problem. We are investigating. We will keep you updated." would be comforting. 

@acer FWIW, I did your suggested Options setting, and it seems that the problem has disappeared. So, I 🗳  👍 

@acer I vote up for this Answer also, and I'm surprised at how "tight" and unragged you managed to get it with the default grid values.

@Rouben Rostamian  It's an impressive work, Rouben. I wish that I could give this Answer a 2nd Vote Up.

Yes, it can be done. But before I tell you how, I'd like to know whether you want the prime to be used for all derivatives or only for those made with respect to a specific variable (of your choosing), such as x.

@vv I vote up. However, I'd change numpoints= n to grid= [i, j] in plot3d commands purely for pedagogical reasons. 

[This Comment is unrelated to your undefined issue.] Egads, does this mean that the default is now to show that ugly e warning every time e is used as a variable, even in 1D input? Can't that crap be reserved for the newbies using 2D Input?

@C_R I don't know much about MapleSim---so I don't know if this is relevant---but wouldn't the different moments of inertia between tori and cylinders be significant? I'd guess (just from visual observation) that "standard" train wheels are fairly close to cylinders of uniform density steel. But, for example, I'd suspect that bicycle wheels could be closely modeled by tori.

I suspect that degrees are not an allowed option when you have "system" set to "SI".