@Markiyan Hirnyk 

Probably the best thing is to not bother with an answer in the future.

It is a pity that you don't even try to write the expression S(n) in Maple. It should be easy for a beginner.

@Markiyan Hirnyk 

I don't think that more than this can be said on your question. There are 2 options:
1. Choose the prefered order.
2. Let Maple choose the one which is easier for the program.

Edit. What is unknown is the default order. You don't need it, and the result shows the order which was used as I have explained. If you really want to know the default order you have also two options:
1. Look at the source code
2. Ask the developper.

@Markiyan Hirnyk 

For Maple ю, щ   are just 2 distinct symbols. The default order is not mentioned in the documentation but the user can choose his prefered one if he wants.

@Markiyan Hirnyk 

Here you did not provide an order for the variables, so a the program has chosen [ю, щ] for you
and has decomposed the solution set into 7 disjoint cells.

@Markiyan Hirnyk 

RegularChains is used internally by SemiAlgebraic . You need RegularChains only for special manipulations.
As I said, the order of the variables determines the type of the cells. I think that it is clear.

@Markiyan Hirnyk 

As solid people I can say that the first CPV is 3.80259236620486251646441207770...
and the second one is - infinity.

@Markiyan Hirnyk 

Interesting examples. It is possible to compute them using series; direct computations as in your answer would need a very large value for Digits and probably a prohibitive amount of time.

@Markiyan Hirnyk 

This way for a small variation like

f:=exp(-sec(t))*cos(t)/(-1/4+sin(t)^2) + 1/sin(t-Pi/6)^5;

is complicated.

@Carl Love 

The simplification of floor is very weak. Even
simplify(floor(x)) assuming x<1,x>0;
remains unevaluated.

This is not a big problem because the isolation of the singularity usually works.

Unfortunately there is a bug in series which I did not mention in the answer.

series(1/(sin(x)),x=0, 1);
Produces the same error.

AFAIK Maple does not approximate CPV integrals.

@Mariusz Iwaniuk 

@Carl Love 

1. I mentioned d+20 just for safety (e.g. any modern processor also has an extended precision (80 bits) ).  My point was that using hardware floats a hex digit of Pi could be impossible to determine using BBP even for rather small d; for example if this digit is an F and it is surrounded by many F's.  I agree that such situations should be rare, but a warning is OK.

2. In your SSj the hfloats are not used in the first sum which is actually the bottleneck, so increasing Digits by 3 has practically no impact.

@Axel Vogt 

Such situations are actually inherent! I am aware that BBP may miss some trailing hex digits for  some d's, but it was strange that this happened for small d's.

Assume that starting at some position d, the hex digits of Pi are:
3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1234...
(such a d should exist because Pi is probably a normal number).
Now, using hfoat computations, BBP(d+20)  could be any of  FFFFFFFFF  or 000000000
depending on how the round-off errors are combined.
So, e.g. the hex digits  d+20, d+21, ...   simply cannot be computed/guaranteed with BBP and hfloats!