Stack Exchange
DSolve general solution constants setting
The Mathematica Documentation reference for DSolve (https://reference.wolfram.com/language/ref/DSolve.html), subsection Scope/Hyperbolic Partial Differential Equations,  contains an example:
weqn = D[u[x, y, t], {t, 2}] == Laplacian[u[x, y, t], {x, y}];
ic = {u[x, y, 0] == (1/10) (x - x^2) (2 y - y^2), 
   Derivative[0, 0, 1][u][x, y, 0] == 0};
bc = {u[x, 0, t] == 0,
    u[0, y, t] == 0, u[1, y, t] == 0, u[x, 2, t] == 0};
(sol = FullSimplify[u[x,y,t]/.DSolve[{weqn,ic,bc},u,{x,y,t}][[1]],
 K[1]\[Element]Integers && K[2]\[Element]Integers])//TraditionalForm

The solution is a double sum given as

The question is compound:

how come parameters are predetermined, before it is even known that the solution will contain K[ ] and not c1, c2, … labeled parameters?
the Input line defines K[1] and K[2], while the solution contains K[1] and K[3] - why? - looks like a discrepancy.

I would be grateful for any clarifications on the above and also, for some help with finding a way to extract an arbitrary term of the sum or obtain a partial sum, which does not replace only the upper limit, (e.g. infinity), as in all examples with sums as solutions in the Mathematica reference.

With v13.1.0, the result remains a Piecewise solution unless the assumptions are extended to K[1] \[Element] Integers && K[3] \[Element] Integers && K[1] >= 1 && K[3] >= 1. K is used rather than C because they are variables (indices in summations) rather than constants. K is used for variables or arbitrary functions. C is used for arbitrary constants.

Is the look of sol /. {K[1] -> m, K[3] -> n} better to your liking?

the && K[2]\[Element]Integers] is mistake. I remember now seeing this before. May be even asked about it here but can't be sure. There is no K[2] in the solution. So this does nothing. There is only K[1] and K[3]

Thank you. I was not aware of the intended distinction between constants labels. Changing constant names did not help with the last part of my question.
In ref/DSolve - Scope/General Partial Differentia Equations - an example solution  is given as an infinite sum. A finite part is activated by replacing the upper limit, ‘infinity’, of the sum, as follows:
u[k_Integer] = \[Psi] /. Activate[First[sol] /. \[Infinity] -> k]
This would extract the partial sum with the first k terms. What would be the mechanism for extracting any term or partial sum starting from an arbitrary term?

What would be the mechanism for extracting any term or partial sum starting from an arbitrary term? for partial sum I usually just replace $\infty$ with a numerical value  say 50 or 100 or whatever the number of terms you want (using standard /. command). Then Activate the sum. You do need to do this anyway to evaluate the sum and plot the solution.

If sol = FullSimplify[u[x, y, t] /. DSolve[{weqn, ic, bc}, u, {x, y, t}][[1]], K[1] \[Element] PositiveIntegers && K[3] \[Element] PositiveIntegers] (in V13), then the general term of the sum is, First[sol].

Question 1. The K[1] and K[3] are summation variables. This means that they are dummy variables, and any other name could be used instead. They could also be named c1 and c2. For a general discussion, see the Wikipedia entry on free and bound variables.
Question 2. Since summation variables are dummy variables, it is quite possible that different versions of Mathematica produce solutions with different summation variables. I looked at the Mathematica documentation for DSolve for versions v12 and v13:

https://reference.wolfram.com/legacy/language/v12/ref/DSolve.html
https://reference.wolfram.com/legacy/language/v13/ref/DSolve.html

It seems that v12 used K[1], K[2] and that v13 used K[1], K[3]. OP seems to have code from the documentation v12 (or similar) but the output for v13 (or similar) which explains the discrepancy.
Extracting finitely many terms. One can use something like
sol/.{{K[1],1,DirectedInfinity[1]}->{K[1],1,5},
      {K[3],1,DirectedInfinity[1]}->{K[3],1,10}}//Activate


Btw, I think this is a rather ugly example in the documentation. The post-processing using FullSimplify should not be necessary.

Thank you for the precise and helpful answer! Especially, the last part, which worked for my problem beautifully. I did search the documentation for guidance, but could not find and would non have been able to work it out exactly on my own. Gratefully,

You are welcome.
