Agreed. Instead of actually deleting the user account in the database system, it should rather be flagged as deleted. All posts made by that user can be hidden based on that flag, and the record eventually deleted permanently after a grace period of e.g. 7 days (before that, moderators would be allowed to reactivate the account and undo their slip).

[-] 001 ABC PQR should stay aligned to the top IMO, so that it does not "jump" when expanding or collapsing. As long as there are vertical and horizontal lines for the subjects, marks and percentages, it should be clear that ID, First Name and Last Name apply to all rows to the right.

A gradient as mentioned in 3. is known as "scrim" in Material Design (see Text Protection)

I would argue that there's a scrollbar on desktops and also on touch devices as soon as you start scroll - which happens pretty naturally.

I'm a fan of E-mail: [[email protected]], although I prefer the Material Design approach (icon + placeholder and optional floating label): google.com/design/spec/components/text-fields.html

"Send notification in: # min." + tooltip "you will receive an automatic email with updated appointment details when no more changes are made, as soon as the countdown reaches zero."?

As long as the popup can also be closed by tapping or clicking the dimmed area around it, I don't really care :D

Maybe a toolbar at the top with a countdown until notification is sent + a brief explanation? You could put buttons there to adjust current countdown, cancel entirely and a link to where you can change the default delay. The countdown could be smart about the appointments, like don't send notifications until 1 week before start date. Or maybe just once daily? (a button to send a notification immediately might be desired in this solution)

If you compare the size of the text informing the user about the action carried out on his/her behalf, and the size of the Undo button, then it's apparent that 90% are input feedback and only 10% presumption of an error. Furthermore, there is usually no menu Edit > Undo on mobile devices and no shortcut Ctrl+Z. Toast message + Undo button is the perfect solution IMO, and I prefer it on desktop computers too over confirmation dialogs that go on my nerves and impede my workflow. There should be another way to undo once the toast message is gone of course; it my require more effort though.

I believe it can save some vertical space, depending on the implementation. I guessed that could count as solution to a design problem. It may not outweigh the drawbacks still.

Show me research on this or the hordes of confused users of apps which do allow the deletion while on object level. So far it's only your opinion against my examples apparently proving you wrong… IMO there's a reasonable flow.

I falsified your claim that a document could never be deleted while it's opened. One could see Notepad as the exception to the rule, but the point is there are prominent exceptions and deleting while on object level is apparently not an issue. Or would you call e.g. Google Photos broken?

Why no internet connection? What about a server in the local network to exchange data (e.g. Wi-Fi)?

There are workarounds to JavaScript's slightly problematic date/time handling and you can find a developer-friendly library in Moment.js Timezone. Sensor data especially from different timezones should follow ISO 8601 and include the proper time zone designator.

You can delete an opened file on Windows unless the application using it requested a type of access that prevents it. You can test that with Notepad for instance. After removing the file, you will be able to save the file again (it's still in memory). I can't see any inconsistence. You can also close an unsaved Word document (which can be seen as object), while the document is in edit mode and you being on object level. Google Photos let's you delete an image while it is displayed fullscreen (just like any of the other operations like share, edit, info). All you offered are groundless claims.

I find your reasoning rather weak. As merqri points out, the detail screen represents an entity (whether in edit-mode or not) and deleting that entity is a normal operation and therefore belongs there. There should of course be a prompt to the user before removing it irreversibly ("Delete? Unsaved changes will be lost."). Going back to the list page seems sensible, although there are other patterns around. Google's Gmail app allows to configure the behavior, whether you want it to take you back to overview, or go to next / previous email.