Issue 1:
From PkgEvaL: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/c3bb6df_vs_599ecd8/RBNF.1.6.0-DEV-fe2d71bc7f.build-3d16cc1ee71b7eb9.log

I am not sure if the package is doing "bad stuff" but at a glance, it doesn't look like it.

julia: /workspace/srcdir/src/gf.c:153: jl_specializations_get_linfo: Assertion `!jl_types_equal(mi->specTypes, type)' failed.

signal (6): Aborted
in expression starting at /home/pkgeval/.julia/packages/RBNF/mMbsg/test/qasm.jl:104
gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x7fe30e591728)
__assert_fail at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
jl_specializations_get_linfo at /workspace/srcdir/src/gf.c:153
cache_method at /workspace/srcdir/src/gf.c:1032
ml_matches at /workspace/srcdir/src/gf.c:3075
jl_matching_methods at /workspace/srcdir/src/gf.c:1839
_methods_by_ftype at ./reflection.jl:821 [inlined]
#findall#212 at ./compiler/methodtable.jl:57 [inlined]
findall##kw at ./compiler/methodtable.jl:54
jfptr_findallYY.YY.kw_10636.clone_1 at /opt/julia/lib/julia/sys.so (unknown line)
_jl_invoke at /workspace/srcdir/src/gf.c:2172 [inlined]
jl_apply_generic at /workspace/srcdir/src/gf.c:2373
#214 at ./compiler/methodtable.jl:67
get! at ./iddict.jl:163 [inlined]
#findall#213 at ./compiler/methodtable.jl:66 [inlined]
findall##kw at ./compiler/methodtable.jl:65
jfptr_findallYY.YY.kw_10631.clone_1 at /opt/julia/lib/julia/sys.so (unknown line)
_jl_invoke at /workspace/srcdir/src/gf.c:2172 [inlined]
jl_apply_generic at /workspace/srcdir/src/gf.c:2373
abstract_call_gf_by_type at ./compiler/abstractinterpretation.jl:71
abstract_call_known at ./compiler/abstractinterpretation.jl:1003
abstract_call at ./compiler/abstractinterpretation.jl:1026
abstract_apply at ./compiler/abstractinterpretation.jl:715
abstract_call_known at ./compiler/abstractinterpretation.jl:922
abstract_call at ./compiler/abstractinterpretation.jl:1026
abstract_call at ./compiler/abstractinterpretation.jl:1010
abstract_eval_statement at ./compiler/abstractinterpretation.jl:1132
typeinf_local at ./compiler/abstractinterpretation.jl:1386
typeinf_nocycle at ./compiler/abstractinterpretation.jl:1442
_typeinf at ./compiler/typeinfer.jl:212
typeinf at ./compiler/typeinfer.jl:207
typeinf_ext at ./compiler/typeinfer.jl:831
typeinf_ext_toplevel at ./compiler/typeinfer.jl:864
typeinf_ext_toplevel at ./compiler/typeinfer.jl:860
jfptr_typeinf_ext_toplevel_10832.clone_1 at /opt/julia/lib/julia/sys.so (unknown line)
_jl_invoke at /workspace/srcdir/src/gf.c:2172 [inlined]
jl_apply_generic at /workspace/srcdir/src/gf.c:2373
jl_apply at /workspace/srcdir/src/julia.h:1693 [inlined]
jl_type_infer at /workspace/srcdir/src/gf.c:300
jl_generate_fptr at /workspace/srcdir/src/jitlayers.cpp:316
jl_compile_method_internal at /workspace/srcdir/src/gf.c:1924
jl_compile_method_internal at /workspace/srcdir/src/gf.c:2190 [inlined]
_jl_invoke at /workspace/srcdir/src/gf.c:2183 [inlined]
jl_apply_generic at /workspace/srcdir/src/gf.c:2373
#15 at /home/pkgeval/.julia/packages/RBNF/mMbsg/src/NaiveParserc.jl:58
unknown function (ip: 0x7fe2ebc9f5d1)
_jl_invoke at /workspace/srcdir/src/gf.c:2172 [inlined]
jl_apply_generic at /workspace/srcdir/src/gf.c:2373
mainprogram at /home/pkgeval/.julia/packages/RBNF/mMbsg/src/ParserGen.jl:292
runparser at /home/pkgeval/.julia/packages/RBNF/mMbsg/src/ParserGen.jl:213

Issue 2:
These types should print the same (since the type parameters are type-equal), if the datatype cache (and new hash computation) is working correctly:

julia> Val{Tuple{Any}}
Val{Tuple{Any}}

julia> Val{Tuple{T} where T}
Val{Tuple{T} where T}

julia> Val{Tuple{Float64,Int64,Int64}}
Val{Tuple{Float64,Int64,Int64}}

julia> Val{Tuple{Float64,Vararg{T,2}} where T<:Int64}
Val{Tuple{Float64,Vararg{T,2}} where T<:Int64}

julia> Val{Tuple{Float64,T,T} where T<:Int64}
Val{Tuple{Float64,Vararg{T,2}} where T<:Int64}

This is actually an improvement from before the new hash computation code (the last one was previously also creating a unique type). Found these by some quick fuzzing, so I'm pleased to see there weren't more!