The changes we made in the newer version were a little about trade-offs. The old version had a very complex internal design that used multiple sub-controls and was relatively "heavy" in terms of elements. This made them more memory intensive and took user interfaces that made use of many editors (like PropertyGrid) much longer to load. On top of that, it was very inflexible on how dates had to be entered.
The newer version makes use of a single TextBox control in the edit box's template. It's far more lightweight in terms of memory/elements, uses many fewer bindings, and has simpler logic on the inside. Everything runs very fast with the newer design. The downside of the change is that some of the prompting isn't available that was before.
Regarding your questions...
1) That is something we may look into in the future. In the meantime, you might be able to look for the TextBox control within the template (such as in an OnApplyTemplate override, and look for the part named "PART_TextBox"). Then hook into its events to block certain input.
2) A quick note... if you are doing dates only, use DateEditBox instead of DateTimeEditBox. It's pretty flexible in how input is accepted. You could enter dates in common formats like yyyy-MM-dd if you wish. All the processing happens in the protected virtual DateEditBox.TryConvertFromString method, which uses calls like DateTime.TryParseExact, DateTime.TryParse, etc. We also have fallback logic so if you don't type a "/", and enter "02042020", it will parse that as "02/04/2020". So it should already be supporting that. It just won't prompt the "/" characters until the final value is committed. By overriding TryConvertFromString, you could also support things like "today".