While there are quite a few enhancements planned as evident from the issues tracker on github, the subset that is currently being focused on in the near future and what it will be used for is not quite as clear, so while a new release are many weeks away, here is the current focus and a status update of sorts:

“Big changes”:

• Extending the shared memory interface to accept multiple input/output segments for one frameserver. This will, in the libretro and hijack cases, be used for in situ texture manipulation, and for the longer perspective, allow the support for multiple windows (some MAME cases..) and for streaming network A/V transfers (minor details and a lot of testing left).
• Extending the shared memory interface to accept (foreign, external, “non-authoritative”) connections. This is partially related to the previous point, but under certain conditions, allow external processes to connect and act as any other frameserver even though the trust domain has not been explicitly defined in beforehand (as is done with the database for target_launch today). (minor details and a lot of testing left).
• Extending the platform support to EGL/KMS/ARM/… Parts of this was present, but not really emphasized, in the 0.4 release in that we have support for EGL and, in particular, the Raspberry Pi brand. This is was an experimental step to determine how much work would be needed to get things working on more competent ARM platforms. The big thing missing here still is BSD/Linux raw /dev/input- style support for various devices along with select optimizations for some of math intensive parts (particularly a few ARM NEON/softfpu implementations of 4x4matr- mul and 4x4matr- vec3 transforms).
• Getting recursive. Arcan will be capable of using itself as a “hardware” platform, meaning that the shared memory interface will be used for A/V/Input, and that the engine can launch itself (and with different sets of scripts) so that it fills the roll of desktop environment, compositor and “app-engine” all in one. This is experimentally working for video (with some manual labour) but some ways to go still with audio (~a days work to hack together an openAL-soft backend) and input (~another day to translate events properly).
• Engine optimization; tracking changes on a “per rendertarget” basis and only update when something really has changed, and only update dirty areas for the 2D pipeline (quadtree with batching), and “blit-vid-to-vid” using FBOs as an intermediary for dynamic sprite sheets. Clipping, finally, will get a cheaper version for CLIP_SHALLOW on non-rotated objects to work without needing the stencil buffer.

At the same time, some parallel projects are being worked on (like a BSD/Linux terminal emulator, no points for guessing why), with the bigger one being to integrate and tune all the existing networking code for state synchronisation (aka netplay).