can you please give Test Instuctions?

Hm, the parameter usesecure is a Yes/No (1/0) parameter.

<field
name="usesecure"
type="radio"
label="MOD_LOGIN_FIELD_USESECURE_LABEL"
description="MOD_LOGIN_FIELD_USESECURE_DESC"
class="btn-group btn-group-yesno"
default="0"
>
<option value="1">JYES</option>
<option value="0">JNO</option>
</field>

So,

htmlentities($params->get('usesecure'))

and this pr don't make sense at all.

Even if you would inject sth. stupid in parameter usesecure. JRoute::_() is sanitizing it with an (int).
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/application/route.php#L73
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/application/route.php#L84

The same argumentation for pr #17367 to close both prs.

To reproduce the problem please do the following:

Create some contacts with associated tags
Create a menu item of type tagged-elements of contacts type
Publish a login module on that page.
The login form on that page will have a url similar to (when sef url disabled): /index.php?option=com_tags&view=tag&id[0]=2&types[0]=2&Itemid=132

As you can see the emitted html is invalid: the query part has in fact illegal characters in it, '[' and ']'; we should let that chars encoded!

This problem is related to issue "Bug in AbstractUri::buildQuery - invalid HTML emitted ('[' and ']' not encoded in tagged elements list) #21" (joomla-framework/uri#21).

I think the preferred way to solve both problems is solving the above mentioned problem in AbstractUri:buildQuery.

The same is for pr #17367

Probably mbabker in PR #21 is right: changing AbstractUri:buildQuery is not the best option and it could be a dangerous B/C.

So I think the fix suggested here is the solution.

So I think the fix suggested here is the solution.

In parts:
$params->get('usesecure')
results in
'1' or '0'.
It stands for "Use SSL (https)" "yes" or "no". Just a switch.

Thus your
htmlentities($params->get('usesecure'))
results in
htmlentities('1') or htmlentities('0')
that results in
'1' or '0'.

Yes, you obviously are absolutely right!
I detected the problem here (in login form) but it does not originate here and in no way this is a fix.

Sorry, my confusion deriving from a J!3.4.3 workaround...

The problem remains (tagged emelents menu item emits invalid html)

I close this PR and #17367