Protonating all possible sites: the problem in MOL2 file format or the innate Rosetta feature(bug)?

Dear Sir and Madam,

I have performed a lot of attempts in order to conduct the coupled_moves docking with ligand without it protonation. I need to specify that this ligand (in his physiologically active form) has only one Hydrogen on his sulfonamide site. Nevertheless, despite the absence of any other Hydrogens both in input .params, MOL2 and PDB file, a lot of sites (sulfonamide Nitrogen with additional undesirable Hydrogen, as well as some Carbons on a benzene ring and tail) get protonated.
By the way, Ligand_Dock application also protonates all possible ligand sites.

It seems as if the Rosetta software is fixed on idea of conversion the X-ray crystallographic structures into protonated ones. That approach may be appropriate for relaxing the proteins with PDB-data, derived from X-ray crystallographic analysis, but the protonation of ligands or some other non-protein residues without any permission is the huge disregard, which may result in the significant changes in the physical and chemical properties of such compounds as well as the results (energies scoring terms) of protein-ligand docking.
Additionally, I can say that the conformer-generating server Frog2 http://bioserv.rpbs.jussieu.fr/cgi-bin/Frog2 also protonates all available sites, as the Rosetta software.

So, on base of the foregoing statement, I would suppose that the problem may consist not only in Rosetta soft, but in MOL2 file format.
Firstly, I noticed that the sulfonamide Nitrogen changes its own valency upon Hydrogen addition in Avogadro. If Hydrogen addition changes Nitrogen (or any other atom) valency, why would not suppose that the absence of valency preservation for atom gives an opportunity for Rosetta to add that Hydrogen? I should note that some atoms within the structure (e.g., aromatic Nitrogen on the benzene ring) are robust against protonation.

Might anyone here explain me, why some atoms doesn't got protonated whilst other ones do? And how to preserve the valencies of those second atoms in order to prevent their protonation? On the other hand, if that problem consists in any other thing, I will be sincerely grateful for any solution:

UPD: What about another solution, I ran several other Rosetta apps (Coupled_Moves, Relax and Ligand_Dock), tracked their job performance on Bash and found the PDBJobInputter protocol, that underlies in the foundation of their working. Following the logic and order of its (PDBJobInputter protocol) performance and dependencies, I have already found the FullModelParameters class. Would anyone here confirm whether the FullModelParameters class is responsible for such a total protonation of poses, these undergo the Rosetta protocols performances or if I am on the right way to solve this problem, please?

UPD1: I have already tried to find and/or fix that Rosetta protonation bug/feature in such files as PatchOperation (statement: AddProtonChi), FullModelInfo, ResidueTypeBase, MutableResidue, GasteigerAtomSet, SingleLigandRotamerLibrary, PackRotamers and so on... Unfortunately, no one fix hasn't brought any result so far.

My command for coupled_moves on Bash is following:

~/rosetta_src_2020.08.61146_bundle/main/source/bin/coupled_moves.default.linuxgccrelease -s protein_with_ligand.pdb -resfile somefile.res -coupled_moves::backbone_mover backrub -coupled_moves::ligand_mode true -number_ligands 1 -ligand_weight 1.0 -extra_res_fa eza.params -mc_kt 0.6 -boltzmann_kt 0.6 -packing::no_optH false -nstruct 2 -ntrials 500 -save_sequences true -save_structures true > Output.txt

Also, I attach some files for better clarity.

I will be sincerely appreaciated for your response and I am looking forward to it.

Best regards,
Corvin.