Should the FirstValidValue (of a series) ever be less than Bars.FirstActualBar?
[Note that the question is not whether it can but whether it should.]

Sure it can. When you synchronize a secondary series to the primary, bars have to be added to the secondary series. If you feed those synchronized bars to an indicator, the FirstValidValue could occur in that "synthetic" period.

Nonetheless, if you create the indicator for the secondary symbol prior to synchronization, and its series started after the primary/context series, then you would not expect the FirstValidValue to occur prior to FirstActualBar.

That said, we're aware of at least one problem with "Synchronize()" not translating that FirstValidValue properly when dealing with scale changes - it's a bug waiting to be fixed. I'm afraid we'll probably have to add another case to that bug since Synchronize() seems to ignore doing anything with FirstValidValue.

Good points, Cone. I note, however, that you avoided answering my Q directly which was not if FirstValidValue could occur before FirstActualBar (the answer to which I already knew, w and w/o synchronization) but whether it should. Perhaps my Q was cryptic; I didn't mention I was talking about synched series. But I get what you are implying.
*/

It seems to me a lot of indicators - both Standard and Community contributed - use the FirstValidValue as a reference point to start populating the dataseries with values. This may produce unexpected results, for the reasons you mentioned. Even if/when the bugs are fixed, and for the sake of creating more robust scripts, I would suggest the following corollaries flow from these observations (these are particularly relevant for Pair Trading scripts):
1) The trading bar loop should start from the larger of the FirstActualBar values of the symbol pair (plus any period necessary for indicator stability). [Note: If a user doesn't know how to calculate this, just ask.]
2) When creating custom indicators, it may be a better idea to use FirstActualBar rather than FirstValidValue as a reference point. [But even if users mistakenly use FirstValidValue, as long as they follow point #1 they should be able to avoid use of indicators during the synthetic period of a series.]

When you discuss FirstActualBar, you must consider the cases for synchronization since FirstActualBar will always be 0 if you're not working with secondary series. I answered your question directly and completely for both cases of synch.

QUOTE:
2) When creating custom indicators, it may be a better idea to use FirstActualBar rather than FirstValidValue as a reference point.

This is a good point if it were possible.

... well, it should be possible for indicators that take a Bars object as a parameter.

Indicators values (like ROC, ATR values) for the first bars (until bar = period) are always zero.

(That's why I'm rebuilding all indicators that I use with wise mathematical extensions back to bar zero)

Nevertheless, the bar indicated by the FirstValidValue is 0, but the first meaningful value starts at bar = period. Is this intended?

This varies from indicator to indicator. For some, FirstValidValue is set to period (e.g. ATR); for some unstable indicators (in Community Indicators) even 3 times the period; for some, to period + FirstValidValue (e.g. ROC), etc.

Ben,

I thought you might want to know this. There's a related change in upcoming Developer 6.8 release:

QUOTE:
(136816) The EMA indicator is no longer initialized by the mean average of the period. Instead the indicator is now valid from bar 0 using the value of the base DataSeries and updated on successive bars using the IIR filter calculation.