Hi,

I noticed today when when using the scan: ['app'] property in context.json to cover most cases of properties and the like of the beans in the application, any beans with custom properties defined in beans: [] section later on are ignored.

Should the beans being the more specific config not take precedence over the general scan? My use case here is wanting to mock out certain things in a test/dev environment vs. a production environment, and be able to call a different module based on the environment (planning to generate the context.json on startup based on env). The mix of scan and beans would allow sane defaults to minimise boilerplate code in cases where the property set is identically named to the bean needed (covered by scan), but cases that need to branch or don't align exactly in name can be set manually.

In the complex-function-annotation example, here's what I'm requesting it to look like where we want both an engine and testEngine, while allowing the rest to be set up using scan automagically:

{
	"name": "complex_function_annotation",
 "scan": ["app"],
	"beans": [{
		"id": "car",
		"func": "./app/car",
		"scope2": "prototype",
		"props": [{
			"name": "$engine",
			"ref": "testEngine"
		}]
	}, {
		"id": "engine",
		"func": "./app/engine"
	}, {
 "id": "testEngine",
 "func": "./app/testEngine"
 }]
}

where wheel and light don't need to be defined in beans explicitly on account of scan. Is this already already possible but not as straightforward as I'm making it out to be? If not, would it be possible to introduce this functionality?