Rules
Global features should run without modification on any Cucumber implementation. This naturally leads to a common practice: avoid implementation details to surface in features and move them down to the step definitions.
No step definition is to be stored in cucumber-features. Those are kept within each implementation project.
All step definitions required to run the global features must be well documented. Their expected behaviour, the parameters they accept and their failing cases should all be clear and explicit. See Global Step Definitions Specifications.
The features are written in a "balanced" way. No step definition code is included anymore (compared to original Cucumber.rb features) but feature sources are. Have a look at different levels of abstraction that were suggested. The syntax illustrated on example #2 was chosen.
core.feature tests support for "Feature", "Scenario", steps, step parameters, DocStrings and of course step invocation. That's basically all that is needed to start doing useful things with the Cuke.
Any implementation passing that particular "first" feature should be able to run the whole global feature set to test/develop itself. It means that every global feature must stick to those "core" elements and cannot include anything else than that.
That way, any fresh implementation passing that very feature is able to run the set against another instance of itself without failing because it would be lacking support for a particular "advanced" feature element (e.g. backgrounds, scenario outlines, tags, etc.).