In some places, the documentation of the script is written as if the script is a general purpose script for adding intersecting features to SAM files as a tag. But in other places, it becomes clear that there are several assumptions that limit the scope of the script (e.g., miRNA_ID, shifts/extensions) to miRNAs and isomiRs. I think you could clarify that a bit better and perhaps also make a reference to the scripts that produce valid inputs to this file, because it is highly unlikely that someone would create the inputs for this script manually.

Btw, it would have actually been nice to design this script such that it actually is a general purpose script for adding "name" tags for intersecting features to SAM files and do all the other stuff (dealing with alignments that don't have an intersecting feature, dealing with maximum extensions etc) elsewhere. As it is, this script is quite complicated and has basically zero chance of reuse outside of this workflow.

Anyway, not important now - just lessons for the future :)

So please just clarify the scope of the script in the module-level docstring and I think we are ready to go.

I believe the script per se is pretty general: it adds a custom tag showing which features an alignment intersects with. I think the problem comes when defining variables and how it is documented. In this sense, the script appears to be only for miRNAs whose annotations might or might not been previously extended. But if the word extension is changed to shift or range and the description changes to "Allowed shift range between either end of the alignment and the intersecting feature" (or maybe a better description but just for you to get the idea) then it gets more general and the script does not have to change that much.
Another example would be the way the tag format is specified. If instead of using miRNA_ID I use intersecting_feature any kind of sequence can be used as long as it has been intersected using Bedtools intersect.

I suggest to try and make the descriptions and names more general and if you do not see it clear, I will just revert the commit and document a more restricted scope.

Yes, you can do that if you like. The shift stuff is still quite specific, but I think it's best to keep it, so that we can come to an end on this soon and publish the workflow :)