However, its worth noting, that if it wasnt for them persistently making a lot of 'noise' around this particular feature, FreeBSD guys wouldnt come up with their own implementation anytime soon.
[0] https://www.openbsd.org/papers/bsdcan08-sensors.pdf
[1] I attended the BSDCan this was presented at, and sat close to phk and witnessed the exchanges about the technical merits, problems, "'good enough' vs 'good'", but am recalling from memory.
[2] Poul-Henning Kamp, https://twitter.com/bsdphk
Do you know if there are there plans to implement the rest of the important mitigation techniques?
That is because ASLR, by itself, is almost totally worthless, and is meant as a stop-gap to stop certain direct code attacks (vs "data only" attacks). It is a stop-gap because most modern systems are completely riddled with things like infoleaks, and you only need to leak one pointer to actually defeat the setup completely.
The real vector that's sitting around to be killed is control-flow based exploits (e.g. ROP, simple stack smashing, vtable ptr overwrites, all those de jour exploit techniques). You need a powerful form of control-flow integrity to stop this at the software level. You also need a method to actually help mitigate information leaks so they can do less damage, and increase attacker cost (e.g. "execute only pages" are worthless if all users have the same kernel image. I can just download your GENERIC kernel elf image, and just find the opcodes to do e.g. a ROP attack anyway. grsecurity uses compiler plugins that randomize kernel stacks and the compilation method with a particular private seed, at compile-time, so every compiled grsecurity kernel is different from the last one).
TBQH: FreeBSD is probably better off copying the other twenty gazillion exploit mitigation features from grsecurity that can reasonably stop exploits, even by themselves, dead in their tracks - like UDEREF, KERNEXEC, refcount overflows, triggering the kernel on unmarked signed overflow, the compiler plugin features, etc. Those will actually ban classes of exploits outright, every time, and always work, without wasting time through lots of wincing over the finer details, like ASLR.
You won't get to parade "look at our weak ASLR implementation!" (thankfully), but I feel we already have enough of that going around.
I wish more of the HardenedBSD features would land in FreeBSD trunk. Other than that, I'm really glad to see that it's making great progress, like RISC-V support. The address randomization feature in 11 is ASR (not ASLR), per the review comments by the inventor of ASLR (PaX dev), so it's a pity the initial HardenedBSD devs decided to not continue upstreaming things after they felt the ASLR patch review was taking too long. OPNsense seems to be basing itself on HardenedBSD, so that's nice to see.