If you have followup queries for this problem then please add that here instead of spawning wholly separate new Question threads.

The filled implicitplot red region in the plots above is composed of many POLYGONS plotting structures, and errant gaps can appear when transforming onto the sphere. Those can appear as open chinks between the polygon edges, especially apparent upon manual rotation.

Using plot3d directly, instead of implicitplot with filledregions, a smoother surface without gaps can be obtained.

I include the transformed black outline, still made with implicitplot. Remove if desired.

Download Projection_accc.mw

Lastly, I'll point out that I deliberately did not resort to using implicitplot3d, which (even with option style=surface) produces a clunky surface as a collection of 3D polygons. The result doesn't appear smooth unless the grid resolution is so high that the GUI gets very sluggish when rendering/rotating it.

@MaPal93 Your attached worksheet's last collect call works for me.

Download collect_M_ac.mw

I notice that your attached worksheet did not begin with a restart. I wonder whether there were some earlier computations performed before it was saved.

I don't see how what you've written explains what you mean by the complicated term with which you were trying to "collect" in the line that assigned to `Omega__*`.

The link that Samir gave here is no longer working, and while the wayback machine has a cached version of it, its link to the zip file seems to be not archived by them.

@Vortex Is there a reason why you cannot show us the complete set of commands that you've used, and the version?

@lcz There are various ways to handle your followup query.

with(StringTools):
S := "124e34e243e45e56e76f34e45e23ea12e98e34e43":

parse~([seq(Select(IsDigit,S))]);

   [1, 2, 4, 3, 4, 2, 4, 3, 4, 5, 5, 6, 7, 6, 3, 4,
    4, 5, 2, 3, 1, 2, 9, 8, 3, 4, 4, 3]

parse~([seq(RegSubs("[A-z]"="",S))]);

   [1, 2, 4, 3, 4, 2, 4, 3, 4, 5, 5, 6, 7, 6, 3, 4,
    4, 5, 2, 3, 1, 2, 9, 8, 3, 4, 4, 3]

We don't know whether you'd always need your original operation as well as the first (in which case it might be more efficient to simply split an earlier result). Eg.

with(StringTools):
S := "124e34e243e45e56e76f34e45e23ea12e98e34e43":
T := Split(S,cat(seq("A".."z"))):

parse~(T);

     [124, 34, 243, 45, 56, 76, 34, 45, 23, 12, 98, 34, 43]

parse~(seq~(T));

   [1, 2, 4, 3, 4, 2, 4, 3, 4, 5, 5, 6, 7, 6, 3, 4,
    4, 5, 2, 3, 1, 2, 9, 8, 3, 4, 4, 3]

We don't know whether your actual examples might be very large, or what over efficiency you'd need.

You also haven't stated your general case (ie. what non-numeric characters might be present).

Your question is sparse in important details.

Where does Sx come from?

If Sx comes from dsolve(...,numeric) then you might be able to use that command's events facilities. (For example, you might make it halt when the derivative falls under a target value, has a discontinuous drop, etc.)

Why not provide the details?

@Carl Love No problem, I wasn't complaining. I was on my own phone and couldn't remember or check.

ps. There's another form for elementwise -- a prefix form I suppose it could be called, with an indexed name. Eg, for the OP's list of Vectors, fasteners,

    `~`[`~`[convert]](fasteners, unit_free)

Now I'm wondering how that nested `~`[`~`[convert]] might be programmatically folded together for a specified depth (here, two) -- even if in an ugly manner using `?[]` .

@Carl Love Did I forget to mention that one? (I thought that I had...)

Please upload and attach either a file with the data or a worksheet that can generate it.

@Pi Where else but the name c[i] do w or t_pe depend upon i?

What aspect do you think would change, by varying the value of i?

@Pi What expression(s) do you want to differentiate with respect to, and with respect to what?

I find those fundamental aspects unclear from your phrasing.

What is "soltion(1)"?

By "appro_function(1)" do you mean appro_function[1] ?

Please stop posting duplicates of this problem.

If you have difficutlies or issue with the answers given, or additional details, then please add them to this Question thread (using the Reply button) instead of starting wholy separate new Question threads.

@C_R No, please don't spawn a separate Question thread for such a close variant of the same topic you started.

I don't think that the special name form, eg. `#mrow(...);`  gets mspace respected when rendering. Hence the answer to your followup query might be no, not a name.

That's why above I showed a variant with a print-extension for an unevaluated function call.

@C_R Your requirements have changed.

Here is one very crude way to "nudge the Y up a bit". It's not very flexible.

The results render better in my actual Maple GUI (2023.0), without being cut off on the left.

This is all pretty hackish, because it wasn't designed for arbitrary layout. So, YMMV.

Download ts_negmspace2.mw