> 1. Extends an abstract interface to support of a priority

I'm not sure I see the use case for priority support, do you have a
sample use case?

Furthermore, the executor is backed by a thread pool, so tasks can be
run concurrently.

Finally, the ordering is based on real-clock time - not user-provided
timefunc and delayfunc: so the probability of having identical
scheduled time (priority is only used for ties) is virtually 0.

>  and absolute time.

If you want and absolute time, you can simply do:

p.schedule(abstime - time(), fn, args)

I don't see the need to complicate the API.

> 2. Subclass sched.scheduler from this interface and implement missing methods.

There again, I don't see the need.
The goal of ScheduledExecutor is to be consistent with the Executor
interface and futures, not being backward-compatible with the sched
module.

Also, the sched module simply can't support some operations: for
example, it's impossible to have the schedule.run() method wake up
when a new event with a deadline easiest than the current one is
inserted.

Really, there is now reason to make it compatible or similar to the
sched module: this will - it it gets accepted - effectively deprecate
threading.Timer and the sched module (except that the later supports
user-provided time and delay functions, I don't know how often those
are used).