Upstream works fine, probably fixed by the following commit:

commit 7aa08d45031ec7ce5dadb4979471d626367c09cd
Author: Stefano Brivio <sbrivio>
Date:   Wed May 27 22:51:21 2020 +0200

    evaluate: Perform set evaluation on implicitly declared (anonymous) sets
    
    If a set is implicitly declared, set_evaluate() is not called as a
    result of cmd_evaluate_add(), because we're adding in fact something
    else (e.g. a rule). Expression-wise, evaluation still happens as the
    implicit set expression is eventually found in the tree and handled
    by expr_evaluate_set(), but context-wise evaluation (set_evaluate())
    is skipped, and this might be relevant instead.
    
    This is visible in the reported case of an anonymous set including
    concatenated ranges:
    
      # nft add rule t c ip saddr . tcp dport { 192.0.2.1 . 20-30 } accept
      BUG: invalid range expression type concat
      nft: expression.c:1160: range_expr_value_low: Assertion `0' failed.
      Aborted
    
    because we reach do_add_set() without properly evaluated flags and
    set description, and eventually end up in expr_to_intervals(), which
    can't handle that expression.
    
    Explicitly call set_evaluate() as we add anonymous sets into the
    context, and instruct the same function to:
    - skip expression-wise set evaluation if the set is anonymous, as
      that happens later anyway as part of the general tree evaluation
    - skip the insertion in the set cache, as it makes no sense to have
      sets that shouldn't be referenced there
    
    For object maps, the allocation of the expression for set->data is
    already handled by set_evaluate(), so we can now drop that from
    stmt_evaluate_objref_map().
    
    v2:
     - skip insertion of set in cache (Pablo Neira Ayuso)
     - drop double allocation of expression (and leak of the first
       one) for object maps (Pablo Neira Ayuso)
    
    Reported-by: Pablo Neira Ayuso <pablo>
    Reported-by: Phil Sutter <phil>
    Signed-off-by: Stefano Brivio <sbrivio>
    Signed-off-by: Pablo Neira Ayuso <pablo>

Above patch breaks /CoreOS/nftables/Regression/nft-map-with-ipv6-address-type-key-and-integer, a follow-up is needed:

commit 54eb1e16cc4787906fe8206858f0ea0bfb9c1209
Author: Pablo Neira Ayuso <pablo>
Date:   Sun Jun 7 15:23:21 2020 +0200

    evaluate: missing datatype definition in implicit_set_declaration()
    
    set->data from implicit_set_declaration(), otherwise, set_evaluation()
    bails out with:
    
     # nft -f /etc/nftables/inet-filter.nft
     /etc/nftables/inet-filter.nft:8:32-54: Error: map definition does not specify
     mapping data type
                    tcp dport vmap { 22 : jump ssh_input }
                                   ^^^^^^^^^^^^^^^^^^^^^^^
     /etc/nftables/inet-filter.nft:13:26-52: Error: map definition does not specify
     mapping data type
                     iif vmap { "eth0" : jump wan_input }
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    Add a test to cover this case.
    
    Fixes: 7aa08d45031e ("evaluate: Perform set evaluation on implicitly declared (anonymous) sets")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=208093
    Reviewed-by: Stefano Brivio <sbrivio>
    Signed-off-by: Pablo Neira Ayuso <pablo>

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nftables bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:1722