Ok, as it turns out the 4.10 kernel is behaving correctly and other kernels should be denying the 'm' on /dev/zero. Those kernels will likely get an update to fix this.
The problem stems from the fact that usr/bin/makemkvcon has the READ_IMPLIES_X personality bit set. This can be seen with:
$ readelf -lW usr/bin/makemkvcon|grep GNU_STACK
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10
(notice how 'E' is listed). When this bit is set, read access implies execute, and 'm' is a special form of execute (from 'man apparmor.d': 'allow PROT_EXEC with mmap(2) calls') and because we only have '/dev/zero rw', you see the denial. Previously when we looked at the mmap()s in the strace while we only saw PROT_READ and PROT_WRITE, because the personality bit was set, PROT_EXEC was added under mediation. This personality is very problematic on the whole, because it changes the requirements of the permissions and in trying to meet those requirements, it can substantially weaken the policy (eg, normally you 'read' or 'read and exec' or 'read and write', but not 'read, write and exec').
In this very particular case, allowing '/dev/zero m' would not be a problem, because 'man zero' tells us that writes to /dev/zero are simply discarded by the kernel. However, because the program has an executable stack, there is nothing saying that after we fix /dev/zero something else won't pop out needing x or m permissions when it shouldn't. In the future, AppArmor will have language something along the lines of 'allow read_implies_x' which, when the personality bit is set, it will add 'x' implicitly to any read rules. This is not a solution because it merely makes it easier to allow weakened, workaround policy (it is conceivable it could be in a separate snappy interface though).
I suggest approaching upstream and pointing them at https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks so they can improve their code. Currently their code is vulnerable to stack memory attacks and fixing this will meaningfully improve their code everywhere. It just so happens it would also make the 'm' denial go away.