Solved. New commands:

I'm not completely sure that behavior in 1.4 is the correct one.
If I add these two routes:

vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth0
vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth1

I would expect to see both in main routing table, as it is in 1.3 version. I would expect that latest command doesn't overwrite previous command, as user may want/need redundancy for that particular route.
So I think that adding routes to main routing table and not overwriting previous entry is the correct behavior.
IMO in 1.3:

• Second route is added and not overwriten in main routing table -- OK
• But in vyos cli, second route overwrites the first one, when both routes should remain present in config --- Not OK

Task already implemented:

@artooro It still accepts type-name.

Tested on VyOS 1.4-rolling-202201230317

@artooro , please try again using latest version -> vyos-1.4-rolling-202201230317-amd64.iso
Just tested, and for me, it's working as expected.
PR that solves this issue: https://github.com/vyos/vyos-1x/pull/1184

On VyOS 1.4-rolling-202201230317.
Commands:

Tested on latest VyOS 1.4-rolling-202201230317

Error still present on VyOS 1.4-rolling-202201180317

PR: https://github.com/vyos/vyos-1x/pull/1186

Wildcard + should be replaces with *, according to nft man page:

Loading address group described in task and then printing, works OK.

Tested on VyOS 1.4-rolling-202201180317 and working as expected.

Seems solved, Not reproducible on VyOS 1.4-rolling-202201180317

Did did work as expeced

vyos@vyos# run show config comm | grep fire
set firewall ipv6-name FOO rule 10 action 'accept'
set firewall ipv6-name FOO rule 10 icmpv6 type 'echo-request'
set firewall ipv6-name FOO rule 10 protocol 'ipv6-icmp'

Also, while matching parameters valid in nftables, such as echo-reply, commit fails too:

Bug related: https://phabricator.vyos.net/T4186

Resolved in T3873

TCP Flags seems to be working on firewall filter config.

Tested on VyOS 1.4-rolling-202201180317 and working as expected

Tested and working as expected on VyOS 1.4-rolling-202201150317

Think 2 flag options should be added.
According to nft wiki these are all the flags that nft could match: tcp flags { fin, syn, rst, psh, ack, urg, ecn, cwr}

I can see the fix, but now trying invert selection on tcp flags doesn't work

PR: https://github.com/vyos/vyos-1x/pull/1173

Testing this feature in VyOS 1.4-rolling-202201100317 I'm getting some unexpected behavior.
Config:

PR: https://github.com/vyos/vyos-1x/pull/1157

PR: https://github.com/vyos/vyos-1x/pull/1150

Previous example was expanded, in order to test filtering between native bridge interface and vlans interface on bridge.
Filtering rules:

• Filter traffic from vlan br0.55 to br0.66
• Filter traffic from vlan1 to br0.55
• Allow all

Filtering tested on version 1.4-rolling-202201060842

Scenario proposed by @NikolayP gives next content in table ip filter:

Error still present on VyOS 1.4-rolling-202201020317

Configuration tested on 1.3 and 1.4 version.

Known issue with FRR 8.1.
Related bug report: https://phabricator.vyos.net/T4028

It may be related to T4033 ???

Problem seems to be when 2 ip addresses on same network is defined on interface, like this:

This entries:

Same request: T292

Definitely miss behavior is generated by the new interface MGT that was created when assigning MGT vrf to eth0.

Bug still present in 1.3.0-epa2 version.

I have done a lab using 1.3.0-epa2 version, and got no troubles.
Have configured 2 IP addresses on interface, and configured zone based firewall. I'm able to ping everywhere, using both IP addresses of that interface.
Also I checked that counters on firewall rules got increased while pinging from any of both IP addresses.

Same procedure on 1.2.8, when adding new settings to master, it all remains as master.
Log after commit

Well.. Actually when only one dhcp-server shared network is defined, service can be disbable with global disable for dhcp-server

So, in a very very simple config like this, user is not able to enable and disable dhcp-server with just a simple command?

Error still present in 1.3.0-epa2 version:

Other test.
In same lab, pool for LAN subnet was modified:

More tests where done on version 1.3.0-epa1.
First, dhcp_server.py was modified as indicated.

Resolved using

Tests were done using 1.2.8 and 1.3.0-rc6 version.
Same inconvenient present as described.
Problems is that a default route is added in table 220

Maybe, but if the effort is made in order to be able to configure log level, it would be good that it can be set in different levels.
I'm thinking in a mix scenario, where majority of rules may log with info/debug level (for example default accept rules), while other rules may need a warning/error level (some drop rules).

Bug still present.

At least on simple tests, this modification seems to work.
I have tested on version 1.3, first configuring dhcp server for both addresses: for the one that was defined first, and one for the las IP address defined (of course, one instance of dhcp-server running at a time).
If this needs more testes, let me know what I can do for you.