@moshill Thanks: The additional lecture notes helped a great deal. In that case, the procedures can be shortened to:

#Works in any input mode:
conjcl:= proc(kk::integer, p::prime, n::posint)
local q:= p^n-1, k:= kk mod q, L:= Array([k]), K:= k, t;
    for t do K:= K*p mod q; if K=k then break fi; L(t+1):= K od;
    [seq](L) 
end proc
:

#Only works in 1D input:
conjcl:= (kk::integer, p::prime, n::posint)->
local q:= p^n-1, k:= kk mod q, K:= k;
    [do K until (K:= K*p mod q) = k]
:

These procedures will run much faster for large values of p and n (such as might be used in cryptography) because they avoid direct exponentiation and because they avoid incremental list building.

@ianmccr So, I suppose that you consider what I wrote to be so foul and unworkable that it's not even worthy of comment?

@Anthrazit That's the way it was designed. It's not a bug. If I was redesigning it, I'd exclude the last name evaluation "feature" and handle the prettyprinting of tables, procedures, and modules akin to how rtables and objects are currently prettyprinted. But needing to use eval or entries doesn't seem like a big burden. 

@Jankel I use Maple 2022.2 on Windows 10 with a standard 17-inch HD display. My help Table of Contents font spacing looks exactly like what you showed in your original Question above.

@Ronan I think that it would be best to just write, edit, and store everything in plaintext files. It's fine to test and experiment with the GUI (using 1D input), but put the final work in plaintext files.

Regarding 2D Input: It's so corrupt and deviant at this point that to me it's a separate language, akin to an illiterate's gutter dialect. I don't think that a single syntax innovation made to Maple 1D input within the last 5 years has been incorporated into 2D Input. That includes do-until loops; multilevel break and next in do loops; embedded do loops, if and try statements; embedded assignment operators; updating assignment operators; double-indexed for loops; (the list goes on...). Since it seems that no-one is working on these and it's been so many years, I doubt that it'll ever be done.

I agree: That's a horrible font with a huge number of incorrectly used ligatures. The spacing is "gappy". That slows down reading speed.

There seems to be a lot of bad font-spacing in Maple. 

@nm Maple has the builtin command ilog2, which is extremely fast. Note that I'm using the word builtin in the way that it's usually meant in Maple: something that is coded directly in the kernel rather than being coded in the Maple language and stored in an archive/library. I've seen numerous times where you've used built-in (which you always misspell as "build in")^[*1] to refer to any stock Maple command even if it's stored in the library.

type(ilog2, builtin), type(log, builtin);
              true, false

ilog2 is fundamental to nearly every algorithm in computational number theory.

[*1] Build is, of course, an English verb. Almost any English verb can be used as an adjective, but it must first be put in a participial form. The past participle is used if the adjective is being applied to the verb's object, and the present participle is used if it's being applied to the verb's subject. (Being applied to the object is far more common.) The past participle of build is built.

When two or more words are used together as an adjective (especially as an adjective in its usual position---before the noun that it modifies), the words are usually connected with hyphens. Thus the grammatically correct phrase is built-in command.

@acer For bases other than 2 or 10, you can use indexed ilog. So, no floats are needed, and negative integers are allowed:

1 + ilog[3](22), 1 + ilog[3](-22); 
             3, 3

@acer I did not submit a bug report.

Your alternate workaround did occur to me after I posted the Answer while I was making breakfast and washing dishes. Something about the sound of the sink water gets my mind "in the zone". I haven't tested it yet. If it works, it'd be far better than my workaround---something that I wouldn't rush to remove from my code as soon as this bug is fixed. 

The following procedure computes 16 significant digits of the sum in under 1 second using 31995 terms.

restart:
PS4:= proc()
local p4:= 5, P:= <1,2,3,p4>, T:= 1/mul(P), S:= 0., n;
    Digits+= 4;
    for n while S < (S+= (T*= P[1]/(p4:= nextprime(p4)))) do 
        (P[..-2], P[-1]):= (P[2..], p4)
    od;
    evalf[Digits-4](S), n
end proc
:        
Digits:= 16:
CodeTools:-Usage(PS4());
memory used=101.91MiB, alloc change=2.00MiB,
cpu time=687.00ms, real time=687.00ms, gc time=15.62ms

                  0.005929203741189040, 31995

If you use a larger value of Digits, then you'll get even more significant digits. But it takes more time of course.

@nm Although it seems quite likely that member is somewhat faster than has, that's not the main issue. The main issue is that the commands do different things, give different results. For the specific example that the OP presented, those results happen to be the same, but surely it's just a trivial example rather than his main use scenario. Compare:

A:= {b, {a, b}}:
member(a, A);
                             false
has(A, a);
                              true 

#Or perhaps this illustrates the possibly disastrous difference better:
A:= {sin(1)}:  member(1, A), has(A, 1);
                          false, true

Your header says you use Maple 17. I don't know whether it has the index option to max. It's easily possible that an unrecognized option would be ignored by an earlier version. Please do this test

max[index]([2,1]);

If the response is 1, then you have the option.

@Jankel So, you pop up out of nowhere (your MaplePrimes account having been created today), and your first action on MaplePrimes is to post an irrelevant Comment about an 8-year-old Answer? It seems rather suspicious.

The Question is about solving the matrix equation A.X + X.B = C where A, X, B, and C are all square matrices of the same size. My Answer only applies to solving that unusual equation. Your example equation is trivial, and can likely be solved by any symbolic math package via a stock command. In Maple, it's done with 

LinearAlgebra:-LinearSolve(<1, 1; 2, 3>, <a, b>) 

If you have a question about solving matrix/vector equations, then post a Question.

I think that most new users overuse or over-rely on whattype. I was the same way my first few years using Maple. Now, it's been many years since I've used it at all. It's often not telling you the "complete story". It's not the fault of whattype; the problem is that a single type often cannot adequately describe an expression. In colloquial English, I'd say that whattype's response "should be taken with a grain of salt", meaning with a small amount of skepticism (meaning it requires further interpretation or investigation).

The Answer given by @dharr is also totally correct. If anyone thinks that my Answer contradicts anything that he said, then they are misinterpreting what I wrote, and they should ask for clarification.