i'm the author of the EOMA68 standard, and i commented earlier on this forum when i first discovered that the 96boards standard had been released as a fait-accompli final revision without any public consultation of any kind. i've also invited them to contact me for further input and consultation into future 96boards standards and have not received a response. from this we can logically deduce that 96boards is actively not interested in developing clear standards based on an open and public consultation process.
unfortunately, the time to ask for feature requests to be added to any hardware standard is during its development phase, not after it is finalised. sadly, any modifications to the pinouts of a hardware standard (extra features) can, by definition, only cause massive disruption to the existing community, to the point where it could in fact destroy the entire community because nobody can plug in boards that are supposed to be compatible without going through a hugely complex and costly evaluation process - time spent that only increases NREs as well as calls into question the future of the standard. if they can make changes after a standard is finalised, they cannot be trusted to declare that it is finalised, thus throwing the entire standard into question in the first place.
unfortunately, the 96boards standards committee did not ask for public input on the development of this standard, and, as a result, we have some severe design flaws that not only limit its expected lifetime but actually impose on the PROCESSOR DESIGNERS - the fabless semiconductor companies - what they can and cannot do (i.e. what the pinouts of the PROCESSOR must be, what the voltage levels have to be, and so on). in essence: any processor that complies with the 96boards standard is by definition, limited to very specific target markets. this in turn told us (three years ago) that the 96boards standard will either have extremely limited uptake or will be extremely short-lived. it's been three years so far: we only have three available products, thus confirming the assessment made shortly after the fait-accompli was enacted.
the only way by which a standard may be safely modified is if the speed of a particular port (for example SD/MMC) is enhanced but at the same time auto-negotiates to those higher transfer rates OVER THE SAME PINOUTS. for example, 10/100/1000 ethernet all use the same wires and there is auto-negotiation. SD/MMC may use 1, 2, 4 or 8 wires, and may auto-negotiate all the way from SPI-level speeds up to SSD-comparable transfer rates. PCI-e, SATA, USB and many more - they all have this capability to auto-negotiate, and thus are safe to "upgrade" without causing any kind of disruption to a standard. in fact, the standard should in fact take into account (define the possibility of) increased speeds of such interfaces in order to remain relevant. EOMA68 for example can go all the way from USB 1.0 to USB 3.1, giving it a reasonable projected life-expectancy of at least a decade.
in short, awilkie, whilst it sounds reasonable to make feature requests, if the answer is not "no" - which through the deafening silence and lack of timely response from authoritative sources we may reasonably and rationally assume (and hope) that it is in fact "no", you are going to have to use the real-time software-defined PWM bit-banging module that is available in the linux kernel. this module, which i found a year ago, relies on the high-speed timer capability being enabled, as well as there actually being fast enough hardware timers in the processor being available to back up the linux kernel so that software-defined PWM can in fact be provided at all.
you had also better hope that software-defined PWM is sufficiently stable, or that the target product market is not mission-critical or that someone's life is not dependent on this functionality. if it is, you should look at following andy's advice which is to use an I2C-based PWM GPIO chip. although, to be honest, the cost of such ICs is so relatively large that to be honest you might as well look at putting in something like an STM32F072 (which is supported by libopencm3, a software package and associated libre community that i can thoroughly recommend) or any other $1 to $1.50 embedded controller. this has the advantage that you could get a $10 NUCLEO-STM32F072 board (or other EC board) to carry out initial development, rather than have to spend money prototyping up a PCB.
apologies this might not be the answer that you were expecting, but i trust that you appreciate both some insight into why your feature request cannot (safely) be complied with, as well as appreciate the pointers into some alternative ways in which you might safely and cost-effectively engineer a product using the PWM functionality that you were expecting to have. if you have any questions, you need only ask.
http://crowdsupply.com/eoma68 - libre eco-laptop and modular computing