$validate-code returns a simple true | false answer, and a message. There's several circumstances where the actual answer is more nuanced than that - e.g. when the server has a fragment, it might not know whether a code is valid or not. This is generating false errors (should be warnings) in the FHIR validator. 

Also, strong user feedback is that the validator should record errors in the content at a finer granularity than the CodeableConcept. Consider this example:

<code>
 <coding>
  <system value="http://snomed.info/sct"/>
  <version value="20120521"/>
  <code value="blah"/>
  <display value="blah"/>
 </coding>
 <coding>
  <system value="http://loinc.org"/>
  <version value="20120521"/>
  <code value="blah"/>
  <display value="blah"/>
 </coding>
 <text value="something"/>
</code>

There's a series of possible issues with this: wrong versions, invalid codes, invalid displays, incompatible codes, none of the codes meeting the required value set. Strong user feedback is that these issues should be allocated to the actual element that has the problem, instead of just the root code. 

At present, the validator handles this by validating the codings as well as the code as a whole, and uses a custom parameter "valueSetMode" to differentiate the calls, which tells the terminology server what to do for the validator

But it would be better for the terminology server to return a list of discovered issues, with paths into the content, so that a validator can display these more usefully to the user. 

Therefore, propose adding an additional parameter "issues" which is an OperationOutcome resource, with a list of itemised issues with paths constrained to simple FHIRPath like CodeableConcept, CodeableConcept.coding[0], CodeableConcept.coding[1].display, or Coding.display

This doesn't change the use of the result parameter, which is 'true' if the code is known  to be valid, otherwise false.

Terminology servers should be encouraged to pre-adopt this for earlier FHIR versions