Residency status and membership

We are in a pilot year of collecting data for membership in the API and are still in the process of getting vendors certified.  Recently, some concerns have been raised about our reliance on the ResidencyStatusDescriptor on SSA.  In the case of students who have a change in residency status but remain in the same school, we require the first SSA to be ended and a second SSA to be sent so that the residency status for each period is accounted for.  There was discussion around where to collect residency information with what looks like a suggestion that it be collected on SEORA using a ResponsibilityDescriptor of ‘Residency’ (https://tracker.ed-fi.org/browse/DATASTD-1418).

My questions are:

Is SSA or SEORA the Alliance’s preferred way of tracking Residency?

If SSA is preferred, does the Alliance view a requirement for multiple SSA on residency change being as being a concern? (I believe the main argument against this is that student data and relationships exist within the scope of an SSA in many vendor systems.  The ending of an SSA (even with an immediate re-entry) has potentially significant downstream effects such as requiring of replication of program and student roster data for the new enrollment period.) 

If SEORA is preferred, what is the expected authorization?  Is it the resident district’s responsibility to submit the SEORA or the attending district’s?

Because we use SEORA to authorize SSEPEA, if we were to pivot to using SEORA instead of SSA, I believe we would need to extend SEORA to include both the ResidencyStatusDescriptor and ResidentLEA as the attending district would need to be the one submitting the data.   Would it possibly be better to create an entirely new resource- studentResidencyAssociation?