Terminal width can be determined by simply reading the value of $COLUMNS.
Unless that environment variable is unavailable for some reason in this context, in which case please inform me so I can fix this in my own version.

$COLUMS is not set if bash shell is not interactive, like when motd is executed, unless -i is passed, which creates other problems. It can still be set if checkwinsize is set, but requires starting a sub shell. stty is posix and should be fine to use.

https://stackoverflow.com/a/563592

Ah that makes sense, I did have checkwinsize set, but it's probably better to use stty in this context.

Instead of using a fixed range for the maximum column width of a line on the motd we can evaluate the maximal line length dynamically using something like this.

len_motd=$(echo "$motd_logo" | sed -E "s/\\\e\[[0-9;]+m//g" | wc -L)

if (($COLUMNS > $len_motd))
        then echo -ne "$motd_logo"

We read in the motd, strip out any escape sequences, and pass it to wc -L which returns the column count of the longest line.

With $motd_logo being a Heredoc/variable containing the part of the motd liable to being distorted by wrapping

I am aware of that, but no need to do such processing and calling additional external binaries like sed and wc. If motd is updated, the commiter can adjust size. Moreover, 60 is a good default for column width for motd anyways.

Yeah that's a reasonable concern.

As mentioned above utilizing a Heredoc may be desirable in the interest of cleanliness and maintainability.

# Store $IFS for safekeeping
OLD_IFS=$IFS
# Logo portion of the MOTD.
IFS='' read -rd '' motd_logo << LOGO_EOF
\e[47m                \e[0m  \e[1mWelcome to Termux!\e[0m
\e[47m  \e[0m            \e[47m\e[47m  \e[0m
\e[47m  \e[0m  \e[47m  \e[0m        \e[47m  \e[0m  \e[1mDocs:\e[0m   \e[4mtermux.dev/docs\e[0m
\e[47m  \e[0m  \e[47m  \e[0m        \e[47m  \e[0m  \e[1mGitter:\e[0m \e[4mgitter.im/termux/termux\e[0m
\e[47m  \e[0m            \e[47m  \e[0m  \e[1mCommunity:\e[0m \e[4mtermux.dev/community\e[0m
\e[47m  \e[0m            \e[47m\e[47m  \e[0m
\e[47m                \e[0m  \e[1mTermux version:\e[0m ${TERMUX_VERSION-Unknown}
LOGO_EOF

Storing the initial $IFS may be necessary if a user has set a custom Input Field Separator.

No need for heredoc, since it is slower since it requires creation of temp file and also additional utils like read or cat. We are also appending motd variable, so current way is better.

Hmm didn't think of that.

Storing the indent of the motd as a separate variable is a great idea and I will be adopting it into my version as it simplifies handling the indentation significantly.

Same rationale as above regarding Heredocs for cleanliness and maintainability applies here, and to subsequent motd parts.

Concatenating the motd variable with applicable sections is a significantly more elegant approach than my current solution, I will will be adopting it.