The 2017 code release for team 2357 actually contains two implementations. The StreamCode project was used for all competitions and the KCup project which is an experimental re-write that contains some constructs we want to continue to develop and hopefully use in 2018 (the main reason for this release).
Here it is: https://github.com/FRC2357-SystemMeltdown/SteamCode
There are several things in the experimental KCup project that may be of interest to others.
First, is the /KCup/src/edu/wpi/first/wpilibj/command/StateMachineCommand.java abstract class and its related types in the same package. There are also a few sub class implementations in the project that can act as samples. While a CommandGroup enables serial and parallel command execution of child commands, a StateMachineCommand uses child commands to implement a state machine. Another key difference is that a CommandGroup requires the union of all the child required subsystems while a StateMachineCommand requires no subsystems and only the requirements of the active state are consumed at any point in time. There are some restrictions. The most bothersome is that while a CommandGroup can be used as the command for a state in a StateMachineCommand, the reverse is currently not possible, a StateMachineCommand cannot be a child of a CommandGroup (at least not without telling some lies with regard to subsystem requirements).
Second, is the way we use a configuration subsystem to initialize, reset and distribute (to the appropriate subsystem) configuration values read from a properties file.
Third, we are experimenting with having an OI class per subsystem rather than just one (we still do not know if we like this or not). We will probably either go back to one or go all the way with making this another type nested inside each subsystem. One interesting off-shoot of this experiment are the custom joystick button classes we have that fail at initialization if we accidentally put more than one command on a given button (see OneCmdJoystickButton). There is also one that fails if any command is associated with the button (see ReservedJoystickButton). This is to reserve a button for custom trigger use, like our TwoButtonTrigger class that we use to require a button press from both controllers to reset the configuration.
We hope someone finds this useful. Please let us know if you have questions, use any of it or make some modifications that work out for you and may work out for others.